Um engenheiro júnior faz code review para encontrar bugs. Um engenheiro pleno faz code review para garantir que o código funciona, é legível, e segue padrões. Um Staff Engineer faz code review para desenvolver o time.

A diferença é de objetivo, não de rigor. E esse objetivo muda completamente o que você prioriza nos comentários, como você escreve, e o que você deixa passar.

O que o review de um Staff Engineer não deve ser

Antes de falar o que deve ser, vale nomear os anti-patterns que enfraquecem reviews de sêniors:

Nitpicking de estilo: se você tem um linter, deixa o linter reclamar. Comentários como "espaçamento aqui" ou "prefiro ponto e vírgula" são ruído. Automatize o que pode ser automatizado, e use seu tempo para o que não pode.

Reescrever o código na review: comentários como "eu faria assim: [20 linhas de código]" raramente ensinam — eles impõem. A pessoa aprende a se tornar você, não a pensar por si mesma.

Aprovar sem ler: "LGTM" automático não serve o time. Se você não tem tempo para revisar, diga isso — não finja revisar.

Bloquear por preferências, não por princípios: existe diferença entre "isso viola o nosso padrão de tratamento de erro" (princípio com razão documentada) e "eu prefiro Promises a async/await" (preferência pessoal). Reviews que bloqueiam por preferências criam atrito sem valor.

O que transfere conhecimento de verdade

O formato de comentário mais eficaz não é uma correção — é uma pergunta ou uma explicação com contexto:

// Fraco:
// "Use memoização aqui"

// Forte:
// "Este componente re-renderiza a cada mudança de estado do pai, mesmo quando
// a prop `items` não muda. useMemo nesse cálculo ou React.memo no componente
// evitaria re-renders desnecessários em listas grandes.
// Referência interna: discutimos isso quando tínhamos problemas de performance
// na tela de pedidos — issue #847."

A versão forte explica por que, conecta ao impacto, e linka para contexto histórico. A pessoa não aprende só a corrigir — aprende a raciocinar.

Como categorizar comentários

Uma prática que reduz mal-entendidos: deixar explícito o peso de cada comentário.

  • Bloqueador: precisa ser corrigido antes de merge. Segurança, corretude, violação de contrato de API. Seja específico sobre o risco.
  • Sugestão: você recomenda mas não bloqueia. "Sugiro extrair isso para um helper — ficaria mais testável, mas entendo se você preferir deixar inline por ora."
  • Nitpick: opinião sem peso. "Nit: prefiro o nome `fetchUser` a `getUser` por consistência, mas não precisa mudar." O autor sabe que pode ignorar.
  • Curiosidade/pergunta: você está aprendendo, não criticando. "Por que você escolheu Map aqui em vez de objeto literal? Curioso para entender o raciocínio."

O comentário que poucos escrevem: o elogio específico

Code review não é só sobre problemas. Quando você vê código particularmente bem feito (uma abstração elegante, um teste cuidadoso, uma solução simples para um problema complexo), diga isso explicitamente:

// "Gostei muito dessa abordagem — usar um discriminated union aqui torna
// impossível representar estado inválido. Vou usar essa mesma ideia no
// módulo de pagamentos que estou trabalhando."

Elogios específicos fazem duas coisas: reforçam o comportamento que você quer ver mais, e criam um ambiente onde a review não é só um gauntlet a ser sobrevivido.

Reviews assíncronos vs. síncronos

Comentários de review escalam mal para discussões complexas. Se uma thread de comentário chegou em 4+ respostas, ela deveria ser uma conversa — síncrona ou via voice note. Decisões tomadas nessas conversas devem ser documentadas de volta no PR.

Para mudanças arquiteturais grandes, considere fazer a revisão antes do código ser escrito — um RFC ou design doc que pode ser comentado enquanto ainda é barato mudar.

O que um Staff Engineer deixa passar (de propósito)

Parte da maturidade em reviews é saber o que não comentar. Código que não é ideal mas funciona, é mantível e não viola princípios — deixa passar. Você tem contexto que o autor não tem, mas o autor também tem contexto que você não tem.

Nem todo PR precisa resultar no código que você teria escrito. Às vezes o objetivo é que o time entregue, aprenda com o processo, e melhore no próximo. Bloquear PRs por padrão mais alto do que o necessário é um custo de velocidade que nem sempre vale.