8 coisas para talvez melhorar o code review do seu time
Por Mateus Pereira
Engineering Manager na Quero Educação
Sou apaixonado por code review.
No mundo da engenharia de software, temos inúmeras cerimônias* que visam tornar o time mais unido, mais capacitado, mais ágil, mais coeso, mais eficiente, mais feliz, etc. Em geral, cada uma das cerimônias visam atacar 1 ou 2 desses pontos. Mas tem uma delas que ataca tudo isso e ela chama Code Review. ❤️
Porém, fazer code review por uma mera “burocracia” pode até tornar as coisas piores. Uma forma de garantir que isso não vai acontecer é CONVERSAR SOBRE CODE REVIEW, e é isso que esse artigo quer provocar. Nada do que esteja escrito aqui é lei, regra, o “certo” ou a verdade absoluta. É só o que funcionou para o nosso time e talvez funcione pra você.
*são técnicas, processos ou qualquer outro nome que você queira dar pros costumes que temos em times de engenharia
Vamos começar pela importância?
O code review é o momento onde garantimos que estamos escrevendo um código que atenda à necessidade do cliente e que esteja de acordo com os padrões de design e qualidade definidos pelo time.
O código, antes de tudo, deve atender a necessidade do cliente (aqui entenda-se por qualquer cliente… outro dev, outro time da empresa, o cliente final, etc). Se isso não for verdade, muito provavelmente não deveríamos ter escrito esse monte de instruções pra máquina.
Depois disso, é hora de ver se o código que foi escrito cumpre o que foi combinado pelo time em relação ao código escrito em si. Vamos entrar em mais detalhes daqui a pouco.
Se code review fosse só pra achar erro no código de outro programador, não precisaríamos dele.
Quem são os responsáveis?
Os reviewers do PR são tão responsáveis pelo código que está entrando quanto o autor do PR. Até aqui nenhuma novidade, né? Masss…
Não devia ser necessário ficar implorando review. O autor não é responsável por ficar te cobrando de fazer review do PR dele. Se sua foto apareceu no Pull Request, se organize, pare e faça.
Afinal, quais são as 8 coisas?
0 → O código funciona? Nada é mais importante do que ter a certeza de que o código funciona. Por isso, antes de se preocupar com nome de variável, clean code, tamanho do botão, garanta que o que está escrito funciona. Pra isso, veja os testes automatizados, o ambiente de homologação e o que mais for preciso pra garantir que funcione. Fique atento aos edge cases. Happy path não é feature funcionando, tá?
1 → Entenda o que está sendo resolvido. Sem entender o problema que está sendo resolvido, dificilmente você vai entender o design da solução criada e muito menos encontrar possíveis problemas. Caso você não conheça o que está sendo resolvido, converse com o autor antes de fazer o review
2 → Comece pelas alterações “principais”. A partir desse ponto, você provavelmente vai chegar em todos outros pontos alterados no PR e será mais fácil de entender o design da solução.
3 → Preste atenção no design da solução. Veja as classes, módulos, arquivos e métodos que foram criados e como eles interagem entre si. Os arquivos foram adicionados no lugar correto? Os métodos criados estão na classe correta?
4 → Busque melhoria ao invés de perfeição. O código que está entrando melhora o codebase ou piora? Caso ele melhore, é um forte indicativo que o PR está ok para ir para produção. Isso não quer dizer que você não deve comentar sugestões de melhorias, elas são sempre bem-vindas. Porém, em alguns casos, não devem travar o valor entregue no PR.
5 → Fatos e dados ao invés de opiniões e preferências pessoais. Caso alguma sugestão esteja conflitando entre o autor e o PR, é indicado buscar artigos, referências e/ou dados que comprovem uma solução melhor que a outra. Caso nenhuma das 2 se prove melhor, prevalece a solução do autor.
6 → Recorra ao autor e a outros devs sempre que necessário. Está levando muito tempo? Está mandando vários “wtf” na revisão da solução? Chame o autor do PR (ou outro dev) para revisar junto com você e aproveite o momento pra aprender sobre o conteúdo.
7 → Compartilhe conhecimento. Por favor, ensine! Compartilhe materiais que justifiquem o que você está falando ou que comprovem que o que foi feito está certo. É o momento perfeito pra você ajudar o time a crescer (falo isso por experiência própria, aprendi muitooo com 100 comentários no meu PR kkk).
8 → Elogie! ❤️ Viu algo que resolve algum problema antigo? Alguma solução elegante para um problema complexo? Algum edge case safado coberto nos testes? Manda um ❤️ 👏.
Como saber se o code review do meu time tá bom?
Essas informações vão te ajudar a responder essa pergunta.
- Tem bug indo pra produção? Quanto?
- Quanto tempo demora pra um PR ir para produção?
- O time está satisfeito com a qualidade do codebase? (squad health check pode ajudar aqui)
- Tem features que só um dev sabe mexer?
Conclusão
Use o momento do code review pra criar um laço de companheirismo com seu time. Deixe o ego de lado e ajude o time a crescer.
Ah… o autor do PR pode ajudar na eficiência desse processo também, tá? Mas, outro dia falo sobre isso.
Bônus: o GitHub pode ajudar
Se você estiver dentro de uma organização (e time) no github, essas coisas podem ajudar:
Code review assignment
O GitHub pode marcar os reviewers do PR pra você (e ainda dá pra escolher o algoritmo).
https://github.com/orgs/<org>/teams/<seu-time>/edit/review_assignment
PRs do time
Vocês usam slack? Ele também pode ficar mandando, no canal do seu time, todos os PRs e quem são os responsáveis (essa exposição funciona, acredite kkk).
https://github.com/orgs/<org>/teams/<seu-time>/settings/reminders
E por fim…
Não poderia deixar de agradecer os meus companheiros de time: Guilherme Lourenço, Henrique Santos, João Cruz, Marcos Toledo e Mateus Carneiro
