Para adotar práticas realmente eficientes no processo de code review, é necessário mesclar as soft skills com a capacidade de programar. O arquiteto de soluções e um de nossos especialistas Ronaldo Ronie  explica quais são os benefícios tanto para o time quanto para o produto final em si.

Como desenvolvedores, todos sabemos que fazer code review é bom em teoria. Isso deve nos ajudar a:

  •  Encontre erros e problemas de segurança com antecedência;
  •  Melhorar a legibilidade do nosso código
  • Forneça uma rede de segurança para garantir que todas as tarefas sejam totalmente concluídas.

A realidade é que code review frequentemente podem ser uma experiência desconfortável para todos os envolvidos, levando a revisões combativas, ineficazes ou, pior ainda, simplesmente não acontecendo.

Aqui está um guia rápido para ajudá-lo a criar um processo eficaz de revisão de código:

PORQUÊ fazemos revisões de código?

A primeira pergunta a ser respondida ao revisar seu processo de revisão de código é: qual é o objetivo de nosso code review?

Ao fazer essa pergunta, você logo percebe que existem muitos motivos para executar revisões de código. Você pode até achar que todos na equipe têm uma ideia diferente do motivo pelo qual estão revisando o código. As pessoas  podem pensar que estão revisando pelos motivos:

  •  Para encontrar bugs;
  • Para verificar possíveis problemas de desempenho ou segurança;
  • Para garantir código legível;
  • Para verificar a funcionalidade, faça o que foi necessário;
  • Para garantir que o design seja sólido;
  • Compartilhar o conhecimento dos recursos que foram implementados e o design atualizado;
  •  Para verificar se o código atende aos padrões ou por uma outra dezenas razões.

Se todos na equipe tiverem um “porquê” diferente, estarão procurando coisas diferentes no código. Isso pode levar a vários anti-patterns:

  •  Code review levam muito tempo, pois cada revisor encontrará um conjunto diferente de problemas que precisam ser resolvidos;
  • Os revisores ficam desmotivados, pois cada revisão apresenta diferentes tipos de problemas, dependendo de quem a faz;
  • As revisões podem executar ping-pong entre o revisor e o autor do código, pois cada nova iteração expõe um conjunto diferente de problemas.

Ter um único objetivo para seu code review garante que todos os participantes da revisão, sejam eles autores de código ou revisores, saibam o motivo da revisão e possam concentrar seus esforços para garantir que suas sugestões se encaixem nesse motivo.

O quê você está procurando?

Somente quando entendemos o motivo da revisão, podemos descobrir o quê queremos procurar durante a revisão. Como já começamos a ver, há um grande número de coisas diferentes que poderíamos procurar durante nossa análise, precisamos restringir e especificar os elementos os quais realmente nos importamos.

Por exemplo, se decidimos que o principal objetivo de nossas análises é garantir que o código seja legível e compreensível, gastaremos menos tempo nos preocupando com um design que já foi implementado e mais tempo enfocando em entender os métodos, e se a funcionalidade está em um local que faça sentido. 

O bom efeito colateral dessa opção, em particular, é que, com código mais legível, é mais fácil detectar bugs ou lógicas incorretas. 

Código mais simples também costuma ter melhor desempenho. Sempre devemos automatizar o máximo possível, para que os revisores de código humano nunca se preocupem com o seguinte:

  •  Verificações de formatação e estilo;
  • Cobertura de teste;
  • Se o desempenho atender a requisitos específicos;
  • Problemas comuns de segurança.

De fato, o que um revisor humano deveria enfocar, pode ser bastante simples, afinal – o código é “utilizável”? Ou seja:

  • Legível;
  • De fácil manutenção;
  • Extensível.

 

Essas são verificações que não podem ser automatizadas. E esses são os recursos de código que mais importam para os desenvolvedores a longo prazo. Os desenvolvedores não são os únicos elementos que importam, afinal, o código tem um trabalho a fazer. 

Também é necessário verificar a regra de negócio: o código faz o que deveria fazer? Existe um teste automatizado ou um conjunto de testes para provar isso?

Por fim, atende aos chamados requisitos não funcionais? 

É importante considerar coisas como requisitos regulamentares (por exemplo, auditoria) ou necessidades do usuário (como documentação).

QUEM está envolvido em revisões de código?

Com um objetivo claro e um conjunto de coisas a serem procuradas em uma revisão, é muito mais simples decidir quem deve estar envolvido na revisão. Então precisamos decidir:

Quem revisa o código? 

É tentador supor que deve ser um ou mais desenvolvedores seniores ou experientes. Mas se o enfoque é algo como garantir que o código seja fácil de entender, os juniores podem ser as pessoas corretas para revisá-lo. 

Agora se um desenvolvedor inexperiente puder entender o que está acontecendo no código, provavelmente será fácil para todos entenderem. Se o enfoque da revisão é compartilhar conhecimento, provavelmente você deseja que todos revisem o código. 

Para revisões com outros propósitos, você pode ter um conjunto de revisores e alguns deles são selecionados aleatoriamente para cada revisão.

Quem é o responsável pela revisão? 

Se tivermos mais de um revisor, é importante entender quem é o responsável por dizer que a revisão está concluída. Pode ser uma única pessoa, um conjunto específico de pessoas, um quorum de revisores, especialistas para áreas específicas do código ou a revisão pode até ser interrompida por um único veto. 

Em equipes com altos níveis de confiança, talvez o autor do código decida quando o feedback é suficiente e o código foi atualizado para refletir adequadamente as preocupações levantadas.

Quem resolve as diferenças de opinião? 

As análises podem ter mais de um revisor. Se diferentes revisores têm conselhos conflitantes, como o autor resolve isso? Cabe ao autor decidir? Ou existe um líder ou especialista que pode arbitrar e decidir o melhor caminho? É importante entender como os conflitos são resolvidos durante uma revisão de código.

QUANDO?

“Quando” tem dois componentes importantes:

Quando revisamos? 

Os code reviews tradicionais acontecem quando todo o código está completo e pronto para a produção. Frequentemente, não deverá ser feito o merge a qualquer branch até que uma revisão seja concluída, como é o modelo chamado de pull request. 

Mas esta não é a única abordagem, pois caso uma revisão de código for somente para compartilhamento de conhecimento, a revisão poderá ocorrer após o merge do código. Se a revisão de código for uma revisão incremental que deve ajudar a evoluir o design do código, as revisões serão realizadas durante a implementação. 

Uma vez que sabemos o porquê fazemos revisões ou o quê estamos procurando; e quem participa, podemos decidir com mais facilidade qual é o melhor momento para realizar a revisão.

Quando o code review está concluído? 

Não entender quando uma revisão está concluída é o principal fator que pode levar a arrastar as revisões indefinidamente. Não há nada mais desmotivador do que uma revisão que nunca termina, afinal o desenvolvedor sente que está na mesma atividade desde sempre.

As diretrizes para decidir quando a revisão estiver concluída dependerá de quem está participando da revisão e no momento que essa revisão estiver ocorrendo.

Com knowledge sharing reviews, ele pode ser assinado depois que todos tiverem a chance de examinar o código; Com gateway reviews, geralmente um único sênior indicado (o gatekeeper) diz que está completo quando todos os seus pontos são abordados.

Outros tipos de revisões podem ter um conjunto de critérios que precisam ser aprovados antes que a revisão seja concluída. Por exemplo:

  • Todos os comentários foram tratados por correções no código; 
  • Todos os comentários levaram a alterações de código ou tarefas no JIRA (por exemplo, criação de tarefas para novos recursos ou alterações de design; 
  • Adição de informações para as tarefas de recurso futuros, ou criação de tarefas de débito técnico).

Os comentários sinalizados como mais expressivos (showstoppers) foram todos abordados de alguma forma, comentários que foram observações ou lições a serem aprendidas no futuro não precisam ter sido “consertados”.

ONDE revisaremos?

O code review não precisa acontecer dentro de uma ferramenta de revisão de código. A programação em pares é uma forma de revisão de código. Uma revisão que pode ser um simples diálogo entre colegas, a partir do momento que se verifica uma branch, comentando em um documento, email ou canal de bate-papo. 

Mas por padrão o code review deve ocorrer via pull request, via seu gerenciador de versões, por exemplo github ou bitbucket. 

Uma boa prática, é você mesmo antes de enviar pull request para alguém, realizar uma revisão no seu código para verificar se não esqueceu de nada e antecipar assim possíveis problemas que outra pessoas iriam identificar.

Sumário

Há muitas coisas a considerar ao fazer uma revisão de código, e se nos preocuparmos com todas elas, em cada revisão de código, seria quase impossível qualquer código passar no processo de revisão. A melhor maneira de implementar um processo de revisão de código, que funcione para nós, é considerar:

 Por que estamos fazendo revisões? 

Os revisores têm um trabalho mais fácil com um objetivo claramente definido, e os autores de código terão menos surpresas desagradáveis com o processo de revisão.

 O que estamos procurando? 

Se temos um objetivo, podemos criar um conjunto mais enfocado de coisas para verificar ao revisar o código.

 Quem está envolvido? Quem faz as revisões, quem é responsável pela resolução de conflitos de opinião e quem decide se o código está pronto? Quando analisamos e quando a revisão está completa? 

As revisões podem ocorrer iterativamente enquanto estiver trabalhando no código ou no final do processo. Uma revisão pode durar para sempre se não tivermos uma orientação clara sobre quando o código está finalmente pronto.

Onde revemos? 

O code review não precisa de uma ferramenta específica; uma revisão pode ser tão simples quanto orientar um colega pelo código em nossa mesa. Depois que essas perguntas forem respondidas, poderemos criar um processo de revisão de código que funcione bem para a equipe. 

Lembre-se de que o objetivo de uma revisão deve ser colocar o código em produção e não provar como somos inteligentes.