Fim de ano sempre é sinônimo de reflexão, seja no aspecto pessoal ou profissional. Paramos para refletir sobre o que funcionou e o que não funcionou no ano que termina, fazendo novos planos para o ano que chega. O que podemos melhorar em nossa vida pessoal? E na profissional? Seja qual for sua profissão, uma coisa é sempre certa: seu objetivo é solucionar problemas. O marceneiro resolve o problema da dona de casa ao construir uma nova mesa, o dentista resolve algum problema de carie, o motorista um problema de trânsito e o analista de sistemas um problema de software. Cada um em sua especialidade, sempre procurando a melhor solução.
O famoso físico alemão Albert Einstein dedicou a sua vida a solucionar o maior problema da física até hoje: encontrar uma teoria que explicasse, de forma única, o funcionamento de tudo o que existe no universo. Ele não teve sucesso. Hoje existem algumas teorias que tentam resolver o mesmo problema, entretanto não são soluções simples. Destaquei a palavra simples por um motivo. Einstein acreditava que toda solução deveria ser simples para ser correta. Até os últimos instantes de sua vida ele perseguiu esse ideal. Eu acredito que ele estava certo. Durante o dia nos deparamos com inúmeros desafios, mas será que aplicamos as soluções mais simples? Leia a pequena estória abaixo:

Recentemente recebi um email com um video onde um palestrante contava um caso que ocorreu em uma grande empresa. Era uma fabricante de pastas de dentes, e eles estavam enfrentando alguns processos de clientes que alegavam ter comprado caixas de pastas de dentes vazias. Havia uma falha no processo que fazia com que aleatoriamente algumas caixas não recebessem o tubo de creme dental. Para resolver o problema, os diretores da empresa contrataram uma equipe de engenheiros. Após muitos estudos e testes, os engenheiros criaram um complexo mecanismo composto de uma balança super sensível e um braço mecânico que, ao constatar que a caixa que percorria a esteira estivesse com um peso menor do que o normal, parava a linha de produção e removia a caixa vazia.
O sistema foi colocado em produção e em pouco tempo as reclamações dos clientes pararam. Após alguns meses um dos donos da fábrica foi até a linha de produção averiguar como estavam as coisas, e lá ocorreu o seguinte dialogo com um dos operadores:
- O que vocês acharam do novo sistema?
- Na verdade nós não gostamos muito, porque toda hora a esteira ficava parando pro braço mecânico retirar a caixa. Atrapalhava muito o nosso trabalho e acabamos por deixa-lo desligado – disse o operador.
- Ué, mas ele ficou desligado esse tempo todo? – disse espantado o empresário
- Ficou sim senhor.
- Mas como, se as reclamações dos clientes pararam?
- Na verdade nós resolvemos o problema do nosso jeito. Fizemos uma vaquinha e compramos um ventilador grande pra colocar na altura da esteira. Quando uma caixa vazia passava o vento era mais forte e a jogava pra fora da esteira.
(empresário atônito e mudo)
Quantas vezes não agimos como os caríssimos engenheiros e criamos braços mecânicos para resolver os problemas encontrados diariamente? Será que, como Einstein acreditava, as melhores soluções não são as mais simples? Lembre-se que não basta ter o conhecimento, temos que aplicá-lo com sabedoria, na dose certa. Se para fazer um sistema de venda você teve que aplicar todos os padrões de projeto (design pattern) que conhece, provavelmente não foi a solução mais simples. O algoritmo super complexo que você criou pode ser a prova de erros e resolver todos os problemas que você pensou que fossem ocorrer, em um futuro desconhecido, mas será que foi a melhor escolha agora? Muitas vezes uma solução complexa que resolve todos os problemas de uma vez é mais custosa e trabalhosa de ser mantida do que várias soluções simples, isso porque simples + simples + simples é sempre igual a simples, enquanto o complexo tende a ficar cada vez mais complexo. Em desenvolvimento de software essas situações são freqüentes e pretendo abordar alguns casos em breve. Até lá e um ótimo ano novo.

• Como era o método XYZ da classe FooBar na versão 2.0.3.12 do projeto?

• Quais foram as alterações feitas para incluir suporte à NF-e?

• Quando esta linha de código foi adicionada ao método XYZ?

• Consigo compilar e executar o sistema na versão 2.0.2.15 para reproduzir e consertar o bug de um cliente?

Se o seu controle de versão não consegue responder a estas perguntas, então está na hora de rever as práticas do seu time. Uma ferramenta de controle de versão não deve servir somente como um backup do código fonte, onde, ao final do dia, o desenvolvedor deposita seu trabalho inacabado. Ela deve ser um santuário, o repositório sagrado que exige do desenvolvedor todo respeito e cuidado. Afinal, o artefato mais valioso de um projeto, o código fonte, está guardado ali. Portanto, não basta instalar um controle de versão e sair usando. O time deve rever seus conceitos e absorver as mudanças necessárias, que podem ser dolorosas. No entanto, após um tempo, o time começa a colher os frutos do terreno bem preparado.

Há pouco tempo li um artigo muito bom do Eduardo Miranda sobre gerência de versionamento, onde ele cita algumas práticas boas e ruins. Vamos a elas:

Boas práticas

1. O código-fonte no servidor deve estar sempre pronto para compilação. Ou seja, a qualquer momento do dia deve ser possível buscar a cópia da última versão disponível do servidor e compilar uma nova versão da aplicação.

2. Toda changelist (conjunto de alterações que foram submetidas juntas) submetida visa melhorar o produto, nunca piorar. O código fonte é sagrado e deve ser total e completamente respeitado. Uma changelist corrige um defeito, adiciona uma funcionalidade, refatora um trecho de código. O desenvolvedor não pode submeter changelists que quebrem o build, seja pela adição de erros de compilação ou pela quebra dos testes automatizados. O time com o qual trabalho tem uma prática problemática que é fazer chekins parciais de código para compartilhar com outro desenvolvedor as alterações feitas. Não tem problema, desde que feito em um ramo de versão temporário especialmente criado para isso (também conhecido como branch). Assim, o ramo principal (o chamado trunk) não fica ‘contaminado’ com códigos incompletos. Somente quando toda codificação estiver terminada e os testes unitários completos, podemos fazer um merge do ramo temporário com o ramo principal. Claro que o trabalho é maior devido ao merge, mas a maioria das atuais ferramentas de CVS oferecem um bom suporte para isso.

3. Submeta suas alterações o mais rápido possível e com freqüência. Quanto mais tempo um arquivo fica em alteração mais difícil se torna seu merge e mais aumenta o risco de quebra do build. Divida suas alterações em pequenos pacotes compiláveis e testáveis e submeta sempre.

4. Oh-oh! Atenção, build quebrado! Se o build está quebrado não submeta alterações nem sincronize sua cópia de trabalho. Um build break é um estado que deve ser tratado com a máxima prioridade. Neste estado não é possível garantir que a sua alteração compila e não quebra testes, portanto não é possível garantir sua qualidade. Por outro lado, sincronizar sua cópia de trabalho irá corrompê-la, o que te impedirá de compilar e testar as funções localmente.

5. Controle tudo que é necessário para compilar e instalar a aplicação. Código-fonte não é a única matéria prima para compilação e instalação dos aplicativos. Sua aplicação pode depender de bibliotecas de terceiros. Neste caso, é necessário armazenar no repositório uma cópia do binário na versão utilizada pela aplicação. Em caso de atualização, a nova versão deve ser submetida junto com toda a alteração no código-fonte da sua aplicação necessária para suportar a versão.

6. Estabeleça critérios de qualidade. Código sem erros de compilação é o mínimo aceitável. A partir do momento que o objetivo passa a ser melhorar a aplicação, novos parâmetros de qualidade devem ser adotados para aprovação de um check in: código sem warnings e hints, testes unitários executados, métricas de complexidade mantidas, etc.

Práticas ruins

Qualquer prática que vá de encontro ao objetivo de ter no repositório uma versão compilável, testada e sempre melhor da aplicação, é uma prática ruim e deve ser evitada. Mas algumas são típicas e merecem destaque:

• Não submeta alterações em cima da hora. Sexta-feira, 18h, você louco para ir embora e não estará no sábado de amanhã de prontidão para resolver algum problema.

• Não segure as alterações em sua cópia de trabalho por muito tempo. Código-fonte fora de repositório estraga como comida fora da geladeira. Tentar submeter uma alteração feita há 2 meses no repositório gera um trabalho enorme e um elevado risco de quebra de build.

• Nunca ignore a política de check in. Mesmo alterações simples podem quebrar um build.

Finalizando

O controle de versão é provavelmente a ferramenta mais útil e fundamental no desenvolvimento de software e uma das mais utilizadas no dia-a-dia do desenvolvedor. É necessário sempre se preocupar com a facilidade de uso, para que ela não atrapalhe a produtividade nem caia em desuso, sem, contudo, abrir mão dos seus objetivos primordiais.