Felipe Moacir

Code Review: A Arte de Criticar sem Ofender

Soft SkillsTeamworkCode Quality
Code Review: A Arte de Criticar sem Ofender

Code Review (CR) é a ferramenta mais poderosa para disseminação de conhecimento em um time. Mas também pode ser uma fonte de ansiedade e conflito.

O Objetivo do Code Review

Não é achar culpados. Não é provar que você sabe mais. É garantir que o código que entra na main é sustentável, legível e resolve o problema.

Boas Práticas para quem Revisa

  1. Seja Explícito: Não diga "Isso está confuso". Diga "Eu tive dificuldade de entender a variável X. Sugiro renomear para Y para clareza".
  2. Pergunte, não Mande: Em vez de "Mude isso", tente "O que você acha de extrair essa lógica para um hook?". Isso gera debate técnico.
  3. Elogie: Se viu uma solução inteligente, comente! "Boa sacada usar reduce aqui".

Boas Práticas para quem Submete

  1. Contexto é Rei: Preencha a descrição do PR. Coloque prints, vídeos, links para o ticket do Jira.
  2. PRs Pequenos: Ninguém consegue revisar 2.000 linhas com atenção. Quebre em tarefas menores.
  3. Não leve para o pessoal: O comentário é sobre o código, não sobre você. Você não é seu código.

O que Revisar (e o que Ignorar)

Priorize: Lógica de negócio, segurança, performance, padrões do projeto, testes. Evite: Debates estéticos infinitos, bikeshedding sobre nomes de variáveis quando não há impacto real. Se algo é "questão de gosto", sugestão é melhor que exigência.

Ferramentas que Ajudam

  • Conventional Comments: Padronize prefixos como suggestion:, question:, nit: para que o autor saiba o nível de criticidade.
  • PR Templates: Campos obrigatórios (descrição, como testar) garantem contexto mínimo.
  • CI automatizado: Lint, testes e build quebrados devem ser resolvidos antes da revisão humana focar no que importa.

SLAs de Revisão

Times que definem "PRs devem ser revisados em até X horas" evitam gargalos. O autor não fica bloqueado; o revisor sabe a expectativa. Ajuste o SLA ao tamanho do time e à criticidade do projeto.

Pair Programming como Alternativa

Para mudanças críticas, pair programming pode substituir ou complementar o CR assíncrono. Duas pessoas no mesmo código geram discussão em tempo real e reduzem o ciclo de feedback.

Uma cultura de CR saudável transforma times juniores em times seniores organicamente.