Se quer mesmo ser programador, é bom ir acostumando-se à escrita de códigos. Você vai "quebrar a cabeça", mesmo. Não tem jeito, mas nada melhor do que ver um programa criado por você, um verdadeiro filho seu, rodando perfeitamente. É uma sensação única, uma sensação de "missão cumprida". :-)

Dentro do tópico 'Escrevendo o código', vamos colocar três colunas essenciais para o desenvolvimento dessa parte do artigo:

• Distribuição de módulos e Trabalho em equipe;
• Backup de código e projeto;
• Carga horária de trabalho.

Basicamente, esta parte do artigo será formada pelos três elementos acima.

Distribuição de módulos e Trabalho em equipe

Esta parte é a mais importante. Ela diz respeito à política da empresa, com relação aos seus funcionários encarregados da área de desenvolvimento.

Esta política deve ser estudada e dividida minuciosamente, pois se feita de forma equivocada, pode resultar em um efeito colateral, atrasando os projetos da empresa, que por sua vez pode, até mesmo, resultar em falência. Essas coisas são uma verdadeira bola de neve, e devem receber atenção redobrada.

Para que o tempo de criação de um projeto seja reduzido, é interessante que este mesmo projeto seja destrinchado em partes, e dividindo entre vários desenvolvedores.

Para que não haja certa confusão de códigos, "reinvenções de rodas" - problema muito comum nesses casos, e alterações não comunicadas entre a equipe, é necessário que essa divisão de projeto seja feita de forma estratégica. Vamos imaginar o seguinte projeto:

- Software PDV (ponto de venda), com os seguintes periféricos:

1. Homologado PAF-ECF;
2. Nota Fiscal Eletrônica (NF-e);
3. Geração de boletos bancários;
4. TEF discado.

Neste caso, seria de boa estratégia separar esse PDV em quatro desenvolvedores:

1. Um responsável pelo desenvolvimento do Menu Fiscal do PAF-ECF, seguindo um roteiro de desenvolvimento disponibilizado pelo governo, sendo responsável também pelas atividades internas deste, como geração de relatórios em txt, impressão em ECF (impressora fiscal), SPED, Sintegra e etc.;

2. Um segundo desenvolvedor responsável pelo desenvolvimento do sistema referente à Nota Fiscal Eletrônica, cobrindo também todas as exigências do governo;

3. Um terceiro desenvolvedor responsável pelo módulo referente às impressões, principalmente de geração de boletos bancários (no próximo artigo falarei, inclusive, a respeito de ferramentas e APIs prontas para esse tipo de coisa, para que não seja necessário a reinvenção da roda);

4. E, por último, um quarto desenvolvedor, encarregado de desenvolver uma solução TEF Discada seguindo um roteiro disponibilizado por uma empresa homologadora (Software Express / SevenPDV).

Expliquei de forma bem simplória, pois este tipo de política empresarial, evidentemente, é algo complexo demais para ser resumido em tão poucas linhas, e portanto, necessitaria de um artigo maior e mais profundo acerca do assunto.

Tentei reduzir a coisa e colocar um resumo prático sobre como a coisa funciona. Agora, seguindo essa linha, vamos falar da questão do backup, que é quase que um complemento disso, pois é daí que deve surgir a organização dos arquivos de código fonte, visto que há mais de um desenvolvedor envolvido no projeto.

Backup de código e projeto

Uma coisa muito prática e útil, em empresas onde trabalham vários programadores, é a criação de um servidor de backup, seja ela local ou remoto.

É algo tão prático que você pode fazer o backup de tudo apenas clicando em um botãozinho da IDE, já jogando tudo pro servidor, seja ele na Web, ou em alguma máquina da empresa que sirva como servidor local. E esta facilidade se dá pelos servidores SVN (subversion), que faz controle de versões.

Alguns complementos e plugins para IDEs permitem fazer este upload direto por um clique, como descrevi acima. Procure a solução para sua IDE, de acordo com o seu software de controle de versões.

Eu, particularmente, uso e gosto muito do TortoiseSVN. O TortoiseSVN, além de ter uma fartura de artigos em português brasileiro espalhados pela Web, também conta com uma documentação riquíssima, disponível em 18 idiomas (inclusive o português brasileiro), e que vale ser lida. Veja o link da documentação nas referências abaixo.

Referências

• http://tortoisesvn.net/support.html
• http://pt.wikipedia.org/wiki/Subversion

Carga horária de trabalho

Por último, vou ir direto ao ponto, sem rodeios: você rende muito mais tirando alguns minutos de lazer, do que ficando 8 horas (estou baseando-me na minha carga horária de trabalho) programando direto, se estressando, de cabeça quente.

Você, chefe de empresa que está lendo este artigo, espero que leia e entenda esta parte, pois é importantíssima. Se o desenvolvedor fica sob constante pressão, e por muito tempo, sem descanso algum, ele não vai render, ou melhor, renderá bem menos.

De cabeça quente é difícil resolver problemas, e às vezes dispersar um pouco é necessário. Pensem nisso.