O que eu deveria fazer em um Code Review?
Fala pessoal, tudo bom com vocês? Tem algum sênior com 2 anos de experiência presente entre nós? Identifique-se nos comentários!
Antes de entrar na RD Station (nesse link habemus vagas!), em 2019, nunca tinha trabalhado em um lugar onde o processo de desenvolvimento envolvia um passo de revisão de código, mesmo já tendo participado de projetos grandes no Brasil. Apesar de não ter explicitamente esse passo, às vezes rolavam umas revisões em pares, mas não era comum em todas as tarefas. Algo que em projetos open source já é superado e muito comum, ainda não vejo como sendo uma realidade dentro de muitas empresas, mas posso estar enganado e talvez o cenário tenha mudado rapidamente.
Se você já sabe o que é o code review, pule esse capítulo de Introdução.
Introdução
Pra quem desconhece a prática do code review (ou revisão de código para os que não curtem neologismos) nada mais é que um passo a mais no processo de desenvolvimento de software. Então, quando pensamos numa nova funcionalidade para uma ferramenta ou aplicativo, primeiro vem um processo de descoberta, análise e ideação, que envolve as diversas áreas da empresa e principalmente design, para num segundo momento isso chegar um pouco mais claro para o time de engenharia, seja com desenhos ou um protótipo, ou até algo mais descritivo e bem documentado.
Quando o time de engenharia se reúne para entender o problema que iremos resolver — claro que o time deve e pode ser envolvido antecipadamente, mas aqui quero resumir os fatos — dividimos toda essa descoberta em tarefas e geralmente usamos alguma metodologia para nos ajudar no caminho até a entrega de cada tarefa e de toda a funcionalidade nova.
Os próximos dias das pessoas de engenharia desse time vão se resumir a pegar uma tarefa, realizar aquele escopo ou objetivo daquela tarefa e concluí-la, certo?
Certo, mas qual seria a definição de tarefa concluída?
Na RD, costumamos dizer que uma tarefa pronta é uma tarefa revisada, testada e em produção, não necessariamente disponível para todos os clientes, mas de alguma forma já tem código novo em produção.
O code review nada mais é que essa parte de revisão. Eu executo uma tarefa de desenvolvimento, testo, coloco uma explicação e descrição no que chamamos de pull request (podemos chamar isso de requisição de mudança) e falo para alguém do meu time ou de outro time, caso seja necessário, revisá-la.
Essa pessoa deve aprovar, comentar ou requisitar mudanças no código que você está propondo, da forma que ela achar conveniente, antes que esse código vá para produção. Hoje, quero te dar algumas dicas do que você pode fazer se você for essa pessoa de revisão. Veja, todas as pessoas de engenharia do time devem participar desse passo, não todas numa mesma tarefa, mas revisando alguma tarefa em determinado momento.
Code Review
De acordo com as práticas de engenharia do Google uma pessoa de revisão deve fazer mais ou menos isso aí:
“In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.” — Google's The Standard of Code Review
CL seria o “changelist”, mais conhecido como pull request ou merge request.
Aqui na RD há dois lugares em que citamos o code review, em nosso manual ou playbook de engenharia e no guia de desenvolvimento.
No guia de desenvolvimento, há uma sessão só para o review:
Já no playbook de engenharia, há diversas partes em que falamos das revisões, citamos como referência as práticas de Engenharia do Google, que coloquei acima, e também um artigo interessantíssimo sobre a importância do tamanho do pull/merge request do Rodrigo Miguel nosso gerente de engenharia.
Mas as partes mais interessantes que falam do code review é que podemos fazer mudanças em qualquer repositório e solicitar revisão do time responsável pela funcionalidade (aqui vale citar que usamos uma função chamada code owners do próprio Github), e principalmente que uma pessoa de revisão tem total autoridade para recusar mudanças grandes e solicitar a quebra em mais pull request's.
Dito isso, eu me coloquei no direito de mesclar o que geralmente eu faço nessa hora baseado nos meus aprendizados que tive durante os últimos anos na RD, com o que o time de engenharia do Google coloca como as melhores práticas.
1. Entenda qual era a proposta e o que foi feito
Em primeiro lugar, você precisa entender o porquê daquela mudança, caso não haja uma descrição razoável, já comece por aí!
Em algumas situações, a solução vai exigir de você uma compreensão maior de programação, peça ajuda para validação caso necessite. Concorrência, paralelismo, design patterns e afins podem fazer com que você aprove um design ruim.
Você precisa conseguir testar de ponta a ponta e precisa estar descrito muito bem como fazer isso, a nova era de micro serviços exige que tenhamos um ambiente de testes que funcione bem, e isso deve estar na descrição.
Teste, valide se a solução e os testes foram bem desenhados e implementados e veja se o autor não esqueceu de nada da proposta.
2. Recuse ou solicite mudanças caso necessário
Aqui na RD, nosso processo de integração contínua, que serve para validar se nosso código passou em todos os quesitos necessários para publicarmos em produção, é bem rígido. Lá ele valida algumas condições de estilo, testes e afins, e qualquer item que não esteja em conformidade é passível de obter uma recusa pela pessoa de revisão.
Não entendeu algo no código, peça uma explicação! Não compreendeu a explicação textual, 🔥 no zoom!
Recuse tudo que for muito complexo a ponto de não conseguirmos compreender rapidamente, eventualmente necessitaremos modificar aquele código.
Solicite todas mudanças que achar necessário sem medo de ser feliz, seja a mudança do nome de uma função que só será usada para aquilo, mas não ficou clara, o nome de uma variável, a volta que o programador deu que poderia ser resolvida facilmente de outra forma, passe linha por linha e veja se está tudo de acordo e seguindo os padrões de qualidade da empresa, por exemplo, internacionalização (tradução e localização), acessibilidade, segurança, cobertura dos testes e muitos outros itens.
3. Seja criterioso com os testes e documentação
A falta de testes que verifiquem situações adversas é primordial pra qualquer aplicação hoje em dia, testar erros ou testar o improvável (hahaha), apenas depois de um incidente doloroso sabemos que algumas horas do autor do pull request salvaria aquelas semanas de issues no board do time.
Se for um bug, exija que seja feito um teste para esse cenário!
Só lembramos de documentar coisas em dois momentos, quando alguém do time vai embora ou quando alguém novo entra, e com esse “entra e sai” que acontece cotidianamente em nossa profissão, não custa cutucar seus colegas quanto a esse item, que deveria ser obrigatório em algum nível, em qualquer equipe, direto no pull request, e não em uma tarefa complementar.
4. Elogie a parte boa
Um bom code review é quando fazemos alguma cagada ou escrevemos algo muito rápido e vem alguém com mais contexto, com mais conhecimento sistêmico e nos dá aquela invertida nos comentários.
O exemplo acima é uma figura de linguagem, o intuito do code review é recebê-lo como uma dádiva, um aprendizado, e nunca olhar para a pessoa de revisão como policial diligente e se achar o fora da lei delinquente.
Mas nem sempre um code review precisa ser só correções, aprendizados, detalhes e solicitações de mudança, você pode mandar aquele ❤️ para os mais chegados ou um “BIRRRLLL“ para os monstros, naquelas linhas de código que salvam nosso trabalho!
Deixo mais uma dica de artigo sobre a arte de dar e receber code reviews que se encaixa nessa parte perfeitamente.
Conclusão
Se depois de ler esse artigo e seu time continuar a te questionar o por quê de se implementar e fazer o code review, diga porque está na Bíblia em Provérbios 18:17 rsrs!
A prática do code review dentro dos times é muito importante para o amadurecimento das pessoas de engenharia e aumento da qualidade nas entregas.
Espero que tenha ajudado com algumas idéias do que você pode fazer ao revisar o código de alguém!
Eu estou escrevendo também o Guia Completo do Code Review, me ajude também com sua curtida, comentários e compartilhando!
Guia Completo do Code Review
Parte 1 — Antes da Revisão de Código
Parte 2 — O Papel do Autor
Parte 3 — Em construção
