28 jul 2026 · 4 min de leitura
Code review que funciona (sem guerras de ego)
Checklist curta, comentários objetivos e automação — review bom é processo, não talento.
Bom code review não é caçar bugs de sintaxe — isso é trabalho do linter e do CI. Review humano serve para três coisas: lógica de negócio correta, legibilidade para o próximo developer e partilha de conhecimento da base de código.
A minha checklist: o PR é pequeno (idealmente < 300 linhas)? Tem descrição do porquê, não só do quê? Há testes para a lógica nova? Nomes revelam intenção? Se sim a tudo, aprovo rápido. PRs parados dias são o maior assassino de velocidade nas equipas.
Quanto a tom: comenta o código, nunca a pessoa. "Este método pode falhar se X for nulo, sugiro Y" em vez de "isto está mal". E distingue obrigatório de sugestão — uso prefixos tipo [bloqueante] e [nit] para o autor saber o que exige nova revisão.
Por fim, automatiza o mecânico: formatação, análise estática e testes no CI antes de qualquer olho humano. Cada minuto de review gasto com espaços em branco é um minuto roubado à qualidade real.
Gostaste? Vamos falar do teu projeto.
Sessão gratuita de 20 minutos, sem compromisso.