Code review é um dos processos cruciais no desenvolvimento para garantir a disseminação de conhecimento e das melhores práticas para o time. Dar e receber feedbacks sobre seu código ou Merge Requests - MRs (ou Pull Requests - PRs, dependendo da plataforma usada) é parte essencial na garantia de qualidade das implementações e da evolução de quem está avaliando e quem é avaliado.

As principais vantagens de um code review bem feito são:

  • • Compartilhamento de conhecimento sobre a base de código e negócio;
  • • Identificar em conjunto se é a melhor solução ou se há algo a melhorar;
  • • Propor diferentes abordagens para um mesmo problema;
  • • Garantir que o código segue os padrões arquiteturais e da linguagem;
  • • Encontrar possíveis bugs e vulnerabilidades;
  • • Evoluir o conhecimento de quem participa;

Fases da revisão de código

Um code review pode ser dividido em duas fases.

Fase 1: Revisão rápida

Nesta primeira fase, através do diff (diferença de código), normalmente procura-se o seguinte:

  • • Erros óbvios: erros de digitação, nomes ruins, definições de funções muito grandes;
  • • Código comentado: códigos comentados devem ser excluídos;
  • • Violações dos padrões de arquitetura e codificação que os linters não pegam;
  • • Testes: caso haja (aconselho fortemente a tê-los, garante qualidade e irá poupar trabalho no futuro), validar se os testes foram desenvolvidos e se funcionam;

Idealmente, o desenvolvedor antes de abrir o MR (Merge Request), deve fazer essa mesma revisão, assim poucos problemas desse tipo deverão chegar ao code review. Também, dependendo da quantidade de alterações, um revisor desleixado fará uma revisão dos "termos de serviço": rolar, rolar, rolar, aceitar.

Outro ponto importante é que sejam usadas ferramentas ao seu favor. Um Linter e o uso de EditorConfig pode poupar tempo para focar no que realmente importa.

Fase 2: Revisão de contexto

Essa revisão é mais profunda e possivelmente levará bem mais tempo, pois trata-se de conhecer o contexto da aplicação, da alteração e validar as alterações enviadas em seu MR. Muitos projetos simplesmente forçam com que essa revisão seja ignorada justamente por tomar mais tempo, porém, é ela que pode garantir que os usuários não sofrerão com esses bugs.

Nessa fase, procuram-se items como:

  • • Melhores formas de usar os frameworks/bibliotecas;
  • • Implementações ou refatorações que melhoram a legibilidade, compreensão e capacidade de manutenção;
  • • Você consegue realmente entender o que o código está fazendo? Se está difícil de compreender o código, isso deve ser corrigido/melhorado.
  • • Validar as alterações do MR com a regra de negócio ou contexto da mudança;

Cabe lembrar que há uma correlação entre a quantidade de alterações, a qualidade da revisão e a quantidade de bugs. Quanto mais alterações ou maior for a implementação em um MR, mais difícil será o revisor compreender as alterações e garantir mais qualidade, bem como a quantidade de bugs não percebidos poderá ser maior.

Caso haja dificuldade em compreender o contexto, ou realmente não tenha conhecimento sobre, cabe ao revisor procurar o autor do código para explicar cada uma das alterações.

Formas de tornar seu code review mais eficiente

1. Revisar apenas o que fizer sentido

Se concentre em revisar o que realmente fará diferença. Automatize o máximo que puder, use ferramentas a seu favor.

2. Todos do time devem fazer a revisão

A responsabilidade de revisar não deve ser apenas do mais sênior. Cada desenvolvedor tem sua visão sobre o código, isso pode trazer abordagens melhores na solução do problema.

3. Avalie o código, não a pessoa

O feedback recebido na avaliação do código deve ser entendido como forma de melhorar seus conhecimentos e padrões de codificação.

4. Evite merge requests muito grandes

Combine com a equipe para que os MRs sejam pequenos. O tamanho aconselhável é ser menor que 300 linhas de alterações. Se for maior que isso, divida-o em outros MRs menores.

5. Reúna contexto se estiver faltando

Caso faltem informações, busque essas informações, elas são importantes para evitar mal-entendidos sobre o código e a regra de negócio.

6. Comece em alto nível

Faça a revisão do alto nível para baixo. Evite comentar sobre pequenas mudanças como estilos, indentação, até que as questões maiores, se houverem, sejam abordadas. Assim, o autor pode se concentrar no que é mais importante e inclusive, em alguns casos, os problemas menores desaparecem junto.

7. Forneça justificativa e exemplos de códigos

Caso você discorde de alguma parte do código, é importante fornecer justificativas e exemplos de como fazer da melhor forma. Isso é muito mais útil para o outro desenvolvedor do que apenas escrever "refatorar" no comentário.

8. Discuta sobre o código sempre que possível

Fazer perguntas ao autor e pensar em melhorias em conjunto é a melhor forma de pensar sobre os problemas e chegar nas melhores formas de codificar.

9. Empatia

Mais importante de tudo, lembre-se de que há alguém no final da sua avaliação. Fornecer feedback de forma útil e construtiva fará com que o time evolua.

Conclusão

Depois de um tempo revisando códigos, acredito que code review por pares é a melhor forma para você e seu colega melhorarem o código e as habilidades, não só técnicas. Além disso, é perceptível que cada minuto gasto em uma revisão de código será compensando 10 vezes mais no futuro, garantindo padronização, mais qualidade e evitando que bugs cheguem ao cliente ou usuário.

Uma boa sugestão é criar um documento de padrões de código e um checklist de code review para o time e usá-lo como um requisito para o Definition of Done. Além disso, revisar códigos não deve ser só parte do processo de desenvolvimento, mas uma cultura para uma parte da garantia de qualidade do software.