Code review que funciona (sem guerras de ego)

Há uma ideia errada sobre code review: que serve para caçar bugs de sintaxe. Isso é trabalho do linter e do CI, e fazem-no melhor do que nós. O review humano existe para outras três coisas — validar a lógica de negócio, garantir que o código é legível para o próximo developer e partilhar conhecimento sobre a base de código. Quando o review se foca nestas três coisas, deixa de ser uma discussão de gostos e passa a ser processo.

Começo sempre por uma checklist curta. O PR é pequeno, idealmente abaixo de 300 linhas? Tem descrição do porquê, e não só do quê? Há testes para a lógica nova? Os nomes revelam intenção? Se a resposta for sim a tudo, aprovo depressa. Pode parecer pouco rigoroso, mas é o contrário: PRs parados dias inteiros são o maior assassino de velocidade nas equipas.

Depois vem a tom, que é onde as guerras de ego nascem. Comenta o código, nunca a pessoa. "Este método pode falhar se X for nulo, sugiro Y" comunica muito mais do que "isto está mal". E distingue o que é obrigatório do que é sugestão — uso prefixos como [bloqueante] e [nit] para o autor saber exatamente o que exige nova revisão e o que pode deixar passar.

Por fim, automatiza o mecânico. Formatação, análise estática e testes correm no CI antes de qualquer olho humano tocar no PR. Cada minuto de review gasto com espaços em branco é um minuto roubado à qualidade real — e o teu colega agradece não ter de comentar vírgulas.