O "Code Review" (Revisão de Código) é, estatisticamente, a prática de engenharia com maior retorno sobre investimento (ROI) para prevenir bugs na produção. Contudo, em muitas equipas, os Pull Requests (PRs) tornaram-se num gargalo burocrático onde o revisor simplesmente escreve "LGTM" (Looks Good To Me) e aprova.
Fazer um Code Review de alto nível exige empatia, conhecimento arquitetural e automatização implacável.
Automatize o Trivial
Se um engenheiro sênior está a perder tempo num PR a corrigir indentações, uso incorreto de aspas ou variáveis não utilizadas, a sua Pipeline de CI falhou.
Regra de Ouro: Humanos não devem discutir estilo de código. O linter (ESLint, PHPCS) e o formatador (Prettier, Pint) devem rodar nos pre-commit hooks ou quebrar o build na Cloud antes mesmo do revisor ser notificado.
O Code Review humano existe para analisar o que as máquinas (ainda) não compreendem: Contexto de Negócio e Design de Sistema.
Os 3 Níveis de Análise num PR
Ao abrir um PR, comece do "macro" para o "micro".
Nível 1: Arquitetura e Domínio
A primeira pergunta não é "este código funciona?", mas sim "esta abordagem faz sentido?".
- Essa lógica deveria estar no Frontend ou no Backend?
- O desenvolvedor expôs dados sensíveis num endpoint público?
- A tabela nova do banco de dados tem os índices (
indexes) corretos para evitar slow queries?
Nível 2: Legibilidade e Manutenção
O código é lido 10 vezes mais do que é escrito.
- Os nomes das variáveis refletem o domínio do negócio?
- Funções enormes podem ser refatoradas usando o padrão "Early Return" (Guard Clauses)?
// Ruim: Muito aninhamento (Nesting)
function processUser(user) {
if (user != null) {
if (user.isActive) {
// Processa...
}
}
}
// Excelente: Early Return
function processUser(user) {
if (!user || !user.isActive) return;
// Processa...
}
Nível 3: Segurança e Edge Cases
É aqui que o revisor assume o chapéu de QA e Hacker.
- O que acontece se a API externa demorar 30 segundos a responder? Falta um timeout?
- O payload pode causar um ataque de negação de serviço (DDoS / ReDoS)?
A Regra dos 400 Linhas
Um estudo da Cisco revelou que a capacidade cognitiva de um revisor cai a pique após analisar 400 linhas de código (LOC) de uma vez. PRs com 10.000 linhas não são inspecionados; são aprovados por fadiga.
Divida as entregas em pedaços atómicos. Se precisar fazer uma grande refatoração, separe o PR de "refatorar estrutura" do PR de "adicionar nova feature".
Conclusão
O objetivo do Code Review não é mostrar o quanto você é inteligente encontrando erros nos outros. O objetivo é compartilhar conhecimento corporativo de forma descentralizada. Quando um júnior lê os comentários estruturados num PR, ele está a receber a melhor mentoria possível: aquela contextualizada em problemas reais.