Como fazer code review de verdade sem ser chato ou inútil

1. O propósito real do code review (e o que não é)

Code review não é uma auditoria. Não é um momento de caça aos erros alheios nem uma oportunidade de mostrar quem sabe mais. O propósito real é aprendizado coletivo. Quando você revisa código, está construindo conhecimento compartilhado sobre a base, o domínio e as decisões técnicas do time.

A diferença entre revisão técnica e microgerenciamento está na intenção: se seu comentário existe para controlar como o outro pensa, é microgerenciamento. Se existe para alinhar entendimento e melhorar o resultado, é code review.

O code review se torna inútil em dois cenários opostos: o checklist cego (onde se marca itens sem pensar) e a aprovação automática (onde se aperta "Approve" sem abrir um arquivo). Ambos desperdiçam o potencial da prática.

2. A preparação que ninguém faz (mas deveria)

Antes de abrir o diff, leia o contexto. Entenda qual tarefa, bug ou feature gerou aquele código. Um PR de 500 linhas sem descrição é um convite ao review superficial.

Defina o escopo da revisão: separe o que é obrigatório (o código funciona? é seguro? quebra algo existente?) do que é nice to have (poderia ser mais elegante? daria para extrair um helper?).

Um checklist mental mínimo antes de começar:

1. Funcionamento: o código resolve o problema proposto?
2. Legibilidade: outro dev entende isso em 30 segundos?
3. Manutenibilidade: daqui 6 meses ainda fará sentido?
4. Segurança: há exposição de dados, injeção ou falha de autorização?

3. Como dar feedback sem ser um "code review nazista"

A regra de ouro: separe o código da pessoa. Critique a implementação, não o autor. "Essa função tem um efeito colateral inesperado" é diferente de "Você não pensou nos efeitos colaterais".

Use perguntas em vez de ordens. Compare:

// Ruim
"Refatore isso para usar um switch."

// Bom
"O que você acha de usarmos um switch aqui para deixar os casos mais explícitos?"

Priorize seus comentários em três categorias:

  • Blocker: impede o merge (bug, falha de segurança, quebra de contrato)
  • Sugestão: melhora o código, mas não bloqueia
  • Opinião pessoal: "eu prefiro assim" — pode ser ignorado sem culpa

4. A arte de ler código de forma eficiente

Comece pelos testes. Se o PR não tem teste, o review já começa diferente: você precisa validar manualmente o comportamento. Testes são a documentação viva do que o código deveria fazer.

Leia o diff em camadas:

1. Arquitetura: a estrutura está coerente com o resto do sistema?
2. Lógica: os fluxos principais e de erro estão corretos?
3. Estilo: há padrões inconsistentes?
4. Nomenclatura: os nomes revelam intenção?

Identifique padrões repetidos. Três vezes o mesmo bloco de código é débito técnico. Sugira extrair uma função ou componente.

5. O que realmente importa revisar (e o que ignorar)

Foco no comportamento. Os pontos críticos são:

  • Fluxos de erro: o que acontece quando uma API falha? quando o banco cai?
  • Concorrência: há condições de corrida? estados compartilhados sem proteção?
  • Efeitos colaterais: a função altera estado global? faz chamadas de rede inesperadas?

Ignore formatação. Isso é trabalho para máquina, não para humanos. Automatize com linters e formatters:

// JavaScript/TypeScript → Prettier + ESLint
// PHP → PHP CS Fixer + PHPStan
// Python → Black + Ruff

Valide contratos: entradas, saídas, tipos e interfaces públicas. Uma mudança em uma interface pública pode quebar mil chamadas.

6. Como lidar com conflitos e discordâncias

A linha entre "isso é errado" e "isso é diferente do que eu faria" é tênue. Pergunte-se: há um problema real de performance, segurança ou manutenibilidade? Se não, é preferência pessoal.

Quando escalar uma discordância:

Critérios de decisão (em ordem de prioridade):
1. Segurança: risco para o sistema ou dados
2. Performance: impacto mensurável em tempo ou recurso
3. Simplicidade: complexidade desnecessária
4. Padrão do time: consistência com o resto da base

Se a divergência for técnica real (ex.: qual algoritmo usar), marque uma conversa síncrona de 15 minutos. Decisões de arquitetura não se resolvem em comentários de PR.

7. A cultura de review que faz o time crescer

Considere o code review síncrono (pair review). Sentar junto por 30 minutos para revisar um PR complexo rende mais que 3 dias de idas e vindas em comentários.

Implemente rotação de revisores. Se só os seniors revisam, os juniors não aprendem a revisar — e os seniors viram gargalo. Distribua a responsabilidade.

Métricas que importam de verdade:

- Tempo médio até primeiro review (ideal: < 4h úteis)
- Quantidade de blockers por PR (ideal: 0-2)
- Aprendizado gerado: quantas sugestões viraram padrão do time?

8. Ferramentas e práticas para não perder tempo

Automatize tudo que for possível:

- CI com testes obrigatórios (unitários, integração, e2e)
- Análise estática (SonarQube, CodeClimate, PHPStan nível máximo)
- Linting e formatação automática no commit ou no merge

Controle o tamanho dos PRs. O ideal é até 400 linhas para revisão focada. Acima disso, a taxa de erro de revisão sobe drasticamente. Incentive PRs menores e mais frequentes.

Use um template de PR que ajude o revisor:

## Descrição
[O que esse PR faz?]

## Screenshots
[Se aplicável]

## Checklist do autor
- [ ] Testes unitários adicionados/atualizados
- [ ] Testes manuais realizados
- [ ] Documentação atualizada
- [ ] Sem breaking changes não intencionais

Code review de verdade não é sobre apontar erros. É sobre construir um time que entrega código melhor, juntos. Quando você revisa com empatia, preparo e foco no que importa, o review deixa de ser uma burocracia e vira o momento mais valioso do ciclo de desenvolvimento.

Referências