Nesta seção são apresentadas as práticas de desenvolvimento que nós utilizamos. Nosso objetivo não é apenas passar o dia escrevendo código. Nós entendemos que o trabalho não é o trabalho, e que nosso papel é em ajudar nossos colegas de trabalho, time e clientes a resolverem problemas reais para pessoas reais. O software que construímos faz diferença para nossos clientes, para os clientes dos nossos clientes e para você.

Diretrizes Gerais

Diretrizes de alto-nível:

• Seja consistente;
• Não reescreva código existente para seguir este guia;
• Não viole uma orientação deste guia sem uma boa razão;
• Uma razão é boa quando você consegue convencer alguém do time.

Notas de linguagem:

• “Evite” significa não faça a menos que você tenha um bom motivo;
• “Não” significa que nunca há um bom motivo para fazer;
• “Prefira” indica uma melhor opção e qual sua alternativa a ser observada;
• “Use” é uma instrução positiva.

eXtreme Programming

Nós recomendamos que todo engenheiro de software leia o livro do Kent Beck sobre Programação Extrema (eXtreme Programming). A seguir, nós descrevemos algumas das práticas do XP que nós adotamos:

Testes

Testes unitários ajudam desenvolvedores a realmente considerar o que precisa ser feito. Requisitos são bem definidos pelo uso de testes. Não há má interpretação de uma especificação escrita na forma de código.

Atualmente, nós utilizamos o CircleCI para rodar a suite de testes do projeto.

Desenvolvimento Guiado por Testes (TDD)

Quando você cria seus testes primeiro, antes da implementação, você vai perceber que é muito mais fácil e rápido criar o seu código. O tempo que leva para criar um teste unitário e criar algum código para passá-lo é mais ou menos o mesmo tempo que implementar diretamente. Então, se você já tem os testes unitários você não precisará criá-los após a codificação, economizando um pouco de tempo agora e muito tempo mais tarde.

Além do mais, você terá um feedback imediato enquanto você trabalha. Normalmente não é claro quando um desenvovedor terminou todo trabalho necessário no desenvolvimento de uma funcionalidade. Assim, podendo ocorrer o chamado scope creep, que é quando o escopo do projeto se estende além dos requisitos estipulados pelo cliente. Se criarmos nossos testes unitários primeiro, saberemos quando terminamos a codificação, ou seja, quando todos os testes passarem.