8 coisas para talvez melhorar o code review do seu time

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 e uma forma de garantir que isso não vai acontecer é CONVERSAR SOBRE CODE REVIEW, e é isso que esse artigo quer provocar. Nada do que estiver escrito aqui é lei, regra, o único certo ou verdade absoluta, é só o que funcionou para o nosso time e talvez funcione pra você.

Importância

O code review é o momento onde garantimos que estamos escrevendo um código que atende a necessidade do cliente e que está 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, mais na frente vamos entrar em mais detalhes.

Se code review fosse só pra achar erro no código de outro programador não precisaríamos dele.

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.

As 8 coisas

O código funciona?

Nada é mais importante de ter a certeza 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, ambiente de homologação e o que mais for preciso pra garantir que funciona. Fique atento aos edge cases. Happy path não é feature funcionando, ta?

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

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

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?

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, mas em alguns casos não devem travar o valor entregue no PR

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

Recorra ao autor e 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

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)

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 ta bom?

1. Tem bug indo pra produção? Quanto?
2. Quanto tempo demora pra um PR ir para produção?
3. O time está satisfeito com a qualidade do codebase? (squad health check pode ajudar aqui)
4. 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, ta? Mas outro dia falo sobre isso.

Bônus: o GitHub pode ajudar

Se voce 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 da pra escolher até o algoritimo)

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 PRs e quem são os responsáveis (essa exposição funciona, acredite kkk)

https://github.com/orgs/<org>/teams/<seu-time>/settings/reminders

• aqui entenda-se por técnicas, processos ou qualquer outro nome que voce queira dar pros costumes que temos em times de engenharia