Code Review: por que é importante e tem muito valor
Para deixar nossa conversa mais tranquila e conseguir nivelar todos os leitores, acho legal começar explicando o que é um code review. Assim nossa conversa "mental" fica mais dinâmica e interessante.
Code review é uma das etapas do desenvolvimento ágil. É a parte em que seu "coleguinha" de trabalho avalia se o que você escreveu faz sentido e se existe algum bug ou alguma dica de como fazer o código ficar melhor.
É legal dizer que neste artigo usaremos algumas expressões relacionadas ao Git, caso você tenha alguma dificuldade com estes termos, aconselho a ler meu outro artigo onde explico o que é o git e seus principais comandos.
O por que de o code review ser importante
Já ouvi muitas vezes que ver o código de outra pessoa não é relevante para a empresa, que não trás lucro para o negócio e que isso implica na velocidade em que a tarefa é entregue…
Acho melhor separar os motivos de importância por tópicos, desta forma conseguimos ter uma visão mais detalhada sobre cada ponto que podemos abordar com um code review bem feito:
- Prevenção de erros básicos
Quando algo vira "rotina", deixamos algum erro passar. Essa é literalmente a parte onde é feito o teste de mesa da programação, ou seja, observamos se o if...else cai na condição correta, se o nosso querido for tem necessidade de estar ali e assim por diante. Até mesmo se aquele ponto e virgula não esta sobrando ou faltando.
- Entendimento do que foi alterado;
Lendo os códigos conseguimos entender o que foi alterado e qual sua nova funcionalidade, desta forma é possível manter o alinhamento do time em relação a entregas, pois cada pessoa vê o que foi criado.
- Debater sobre formas de implementação;
"Que tal trocarmos este for por um map…" essa é a hora onde podemos falar sobre uma forma diferente de implantação seja ela por uma forma mais elegante ou por uma questão de performance, estamos livres para comentar e falar sobre como o código foi escrito. Uma dica muito importante é manter padrões, pois vale a pena lembrar que nunca estamos sozinhos em uma empresa e que não ficaremos para sempre lá, então um devemos pensar que códigos bem escritos são a melhor documentação.
- Aprendemos com códigos de outras pessoas;
Nunca uma pessoa pensa igual a outra e é aí que existe uma grande chance de aprendizado. Durante o code review aprendemos e como foi falado no tópico acima podemos perguntar, isso abre portas para techtalks e até mesmo aquela conversa de corredor pra troca de conhecimento.
- Refletimos sobre o valor de uma crítica construtiva.
Nunca é fácil receber uma crítica, mas quando se trata de algo construtivo e que pode ajudar em um crescimento pessoal, ela muito bem vinda. Sempre que algum colega criticar de uma forma construtiva seu código – e como isso acontece todos os dias – vamos aprendendo a receber essas críticas e evoluindo com elas.
Como fazer o code review?
Uma das primeiras coisas que vem em nossa cabeça é a pergunta: "Como eu faço o code review?".
Esta é uma pergunta até que simples de responder… E a resposta é: QUESTIONE! Poxa, mas eu vou questionar o quê? Podemos seguir algumas premissas para questionamento quer servirão de guia para um code review fluido e tranquilo. Então vamos para alguns questionamentos que podem servir de base para ele:
- Eu consigo entender este código?
A primeira pergunta é a mais simples, pois é uma pergunta para nós mesmos. Se você não consegue entender o trecho de código pergunte o que ele faz, as vezes há algum erro ou alguma forma mais clara dele ser escrito e isso ajuda a pessoa que programou a pensar em um código mais legível.
- Existe algum erro óbvio de lógica?
Algumas lógicas conseguimos olhar e ver que estão erradas e quando estamos programando, focados no código elas podem passar despercebidas.
- Olhando para os requisitos, todos os casos são totalmente implementados?
Geralmente quando estamos trabalhando com projetos ágeis, sempre temos uma demanda, como por exemplo: "Quero que os dados do assinante disponíveis nas interfaces, sejam automaticamente retornados…" (Este é uma descrição no formato JTBD (Job To Be Done) onde o P.O. escreve a história o que ele espera que seja feito, porém a forma que será feito é responsabilidade e escolha do time de programadores — caso tenha interesse, deixo a dica de um excelente artigo para entender o formato e o que é o JTBD). Durante o code review, devemos ver se o que foi pedido foi atendido, nesse caso, se os dados foram retornados.
- A cobertura de testes é suficiente para a nova implementação?
Qualidade de código é algo necessário e os testes estão ai para nos ajudar. Eles garantem que o que funciona continuará funcionando.
Durante o code review é hora de ver se o teste realmente testa algo — (podemos encontrar alguns testes validando se true == true) — ou se a cobertura é suficiente para os novos códigos que foram adicionados.
Lembrando que tudo o que existe alguma lógica deve ser testado 🤓
- O novo código está coerente com os guidelines existentes?
Este é um dos itens mais importantes. O padrão que os outros funcionários utilizam está sendo seguido pelo novo código? Caso não esteja é bom apontarmos. Também vale lembrar que conforme a experiência aumenta, nós vamos mudando a forma de programar, então vale a pena voltar naquele código mais antigo e ver se ele ainda faz sentido e refatora-lo se necessário.
Uma coisa que devemos lembrar é que durante o code review, não validamos regra de negócio. O que está sendo avaliado é se o código esta coerente e se não existem erros ou formas melhores de se implementadas.
O que não devemos discutir no code review?
Existe apenas uma coisa bem clara que não discutimos no code review, que são as coisas que podem ser corrigidas com processos automáticos e bom senso da equipe, por exemplo, formatação e indentação de código.
Pra isso existem ferramentas e o bom senso da equipe, no caso para facilitar a vida como um todo, vale a pena configurar o .editorconfig e sempre antes de abrir um novo Pull Request rodar o lint para ver se está tudo certinho e de acordo com os padrões do time.
Dicas que valem ouro
Pra terminar nosso bate papo sobre code review, tenho as últimas 3 dicas de ouro para a hora do code review.
A primeira é que o code review faz parte do nosso trabalho, faz parte do nosso dia-a-dia então trate ele com carinho e encare os comentários como uma forma de aprendizado, não como uma crítica negativa.
Outra coisa legal é separar um tempo para isto, sempre que o Slack piscar com um coleguinha pedindo pra revisar o PR, abra o código e veja com carinho, sem pressa e realmente lendo o código dele.
E por fim, pegue um café ☕️ … Isso torna torna tudo mais fácil, só o trajeto de levantar, sair um pouco da mesa e andar, irá deixar sua mente aberta para novas descobertas e também ajuda na hora de pensar :D
