Peer e Code Review

A revisão pelos pares é uma prática cada vez mais difundida em equipes ágeis, um processo onde um colega revisa o código de outro, com o objetivo de garantir boas práticas de engenharia, domínio, orientação a objetos. Uma opção é a ferramenta Gerrit, por exemplo, e assim como todas as boas práticas ágeis vem a cada ano esvaziando-se a discussão sobre sua validade ou não, mas apenas discute-se a partir de quando vão começar a praticá-las.

Na prática, um ou mais colegas abrem o código construído e opinam sobre sua construção, padrões, camadas, estrutura, etc, indicando pontos de melhoria, refatoramento ou não. Com o tempo a tendência é que este processo gere cada vez maior sinergia e qualificação de todos, gerando bons debates sobre diferentes formas e formas melhores de fazer a mesma coisa. Não é se há bug ou não, mas trata-se de eficiência e eficácia, qualidade de código.

A imagem abaixo eu escolhi porque é muito ilustrativa, mas não entrarei no mérito do uso do Git + Gerrit, mas aqui está o link para quem se interessar em ir além nesta disciplina. O meu post é mais uma percepção de valor no uso da técnica, apresentando motivos e uma visão histórica e conceitual básica, mais que isso fica para mais adiante ou em sites mais root em tecnologia e não metodologia:

csm_Gerrit_workflow_82d0ac5dce

O objetivo não diz respeito a testes, pois diz respeito a padrões de desenvolvimento, momento aproveitado para qualificação de desenvolvedores menos experientes, manutenção de toda a equipe ligada em qualidade de engenharia, garantir boas práticas e estabelecer melhoria contínua. Assim como a programação em pares, a revisão de código entre pares exige um período em que os profissionais aprendem a realizar essa tarefa de forma produtiva e efetiva.

Tenho vários exemplos de práticas de sucesso de programação e revisão de código. Em todas elas sua prática e critérios devem ser transparentes, desde o planejamento da iteração, pois é preciso haver um pacto de time, uma estratégia e metas a serem atingidas. Como tudo o mais, é preciso adequar ao perfil do time, ajustando a sua realidade, tecnologia, número de integrantes, mas a sua prática é inevitável em algumas plataformas e metodologias.

Uma boa prática é não formar duplas constantes, ao invés disso é formada uma tabela de N para N, onde cada desenvolvedor irá trabalhar com outros colegas a cada vez, garantindo uma disseminação real e qualificação de toda a equipe. Um profissional ou equipe que gere atrito no uso dessa prática aponta para a necessidade de uma reflexão sobre o que é auto-organização, agilidade, melhoria contínua, valor e qualidade.

Há vários sites e blogs, como https://www.gerritcodereview.com. A tática mais comum é estabelecer o fluxo de forma que uma história ou feature ou tarefa (conforme sua granularidade no kanban) somente passe para testes após realizarem o peer review, de forma que refatoremos se necessário antes de testar e homologar.

gerrit-2

Já trabalhei em um time em que ao final de cada sprint eles escolhiam uma das classes e juntos faziam uma review onde um desenvolvedor mais senior ou o autor do código apresenta características que chamaram a atenção durante a peer review, abrindo alguns saborosos e descontraídos debates sobre diferentes perspectivas em engenharia de SW.

Em contratos onde o trabalho da equipe de desenvolvimento é homologada pelo cliente, temos além dos testes e homologação funcional, uma avaliação de código que gera apontamentos, ajustes e discussão. Quer revisões N x N ou centralizadas em um profissional mais sênior, o mais importante é haver um processo claro de melhoria coletiva.

Esta prática junto a Pair Programming gera um espiral tão consistente de qualidade, que é muito natural no início sabermos exatamente de quem é o código de uma classe ou método apenas analisando suas características, como uma assinatura digital, lógica, expertise, etc. Esta verdade é relativa em uma equipe que trabalhe com Pair e Review, porque após algum tempo o estilo e domínio na construção de código vai-se elevando e não é incomum confundir-se ao tentar adivinhar quem foi o autor de um código, pois boas práticas e estilo vão-se difundindo, subindo a média de qualidade de todos.

 

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s