A equipe e a qualidade de código

A equipe é, com toda certeza, a que mais tem responsabilidade e controle sobre a qualidade do código. É a equipe que tem consciência da qualidade geral do código e de técnicas que visam a melhoria ou manutenção da mesma.

Das principais técnicas disponíveis, podemos citar:

• Pair programming: 2 desenvolvedores trabalham em um mesmo computador. Comumente usado para tarefas mais complexas, também é muito útil para compartilhar conhecimento quando um dos membros do par tem menos experiência que o outro.
• Code review: seja durante ou ao final do desenvolvimento de uma funcionalidade, um membro da equipe olha o código desenvolvido pelo outro membro. Embora hajam diferentes maneiras de fazer um code review, a que vejo como mais produtiva é quando o desenvolvedor da funcionalidade explica o código para o outro membro. Apenas neste simples processo, é possível enxergar erros e melhorias, que podem vir tanto por parte do autor do código quanto pelo desenvolvedor que faz o papel de revisor.

Muita pessoas citam estas 2 técnicas de desenvolvimento como se fossem opostas. No meu entendimento e experiência, a cada momento uma delas é mais interessante que a outra. Conforme mencionei anteriormente, se a atividade for mais complexa (seja tecnicamente ou pelas regras de negócio), o pair programming mostra sua força, pois atividades complexas abrem margem para um código com grande potencial de bugs e confuso. Com 2 desenvolvedores trabalhando no mesmo código, este risco é atenuado e mais para frente a tendência é economizar tempo, caso este código precise de correções ou evoluções.

O code review funciona bem quando um desenvolvedor com menos experiência termina uma funcionalidade e outro desenvolvedor com mais experiência olha o código. Neste processo, não só erros de lógica e regras de negócio podem ser detectadas, como também ocorre uma transferência de experiência e conhecimento.

Outra coisa interessante do pair programming e do code review, é que temos também um reforço contínuo do que precisa ser feito no desenvolvimento para a qualidade de código ser mantida ou conquistada. Como diria Samuel Johnson:

People need to be reminded more often than they need to be instructed

Voltando ao código, enquanto desenvolvedor, podemos dar o exemplo da checklist, do Code Complete:

• Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency?
• Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format?
• Are all output formats specified for Web pages, reports, and so on?
• [...]

Enquanto equipe, podemos reforçar outros aspectos, também do Code Complete:

• Have you defined how much design will be done up front and how much will be done at the keyboard, while the code is being written?
• Have you defined coding conventions for names, comments, and layout?
• Have you defined specific coding practices that are implied by the architecture, such as how error conditions will be handled, how security will be addressed, what conventions will be used for class interfaces, what standards will apply to reused code, how much to consider performance while coding, and so on?
• [...]

Estes são apenas partes de diversas ações que precisam ser consideradas se a equipe realmente está preocupada com qualidade. Irei futuramente detalhar no blog estes e muitos outros aspectos.