Revisão de código que agrega

Revisão de código tem dois modos de falhar, e os dois são comuns. No primeiro, ela vira gargalo: PRs esperam dias, quem escreveu troca de contexto, e o lote cresce. No segundo, vira carimbo: “LGTM” em trinta segundos num diff de 900 linhas que ninguém leu. Os dois custam caro, e o segundo ainda dá a ilusão de controle.

O que a revisão realmente compra

Em ordem de valor real:

1. Compartilhar contexto. Depois da revisão, mais de uma pessoa entende aquele código. Isso é o que reduz o fator ônibus e acelera o próximo incidente.
2. Detectar problema de projeto. Abstração errada, acoplamento, caso de borda não tratado — coisas que teste não pega.
3. Manter consistência. Convenções que a ferramenta não verifica.
4. Registro de decisão. A discussão do PR responde “por que assim?” dois anos depois.

O que a revisão não compra bem: encontrar bug sutil de concorrência, garantir performance, validar formatação. Para isso existem teste, medição e linter.

Tamanho do PR é a variável dominante

A qualidade da revisão despenca com o tamanho do diff. Acima de umas 400 linhas, a capacidade de encontrar defeito cai bruscamente — e a taxa de aprovação sem comentário sobe, o que é pior.

Alvo prático: menos de 300 linhas alteradas, revisão em menos de um dia útil. Para chegar lá:

• Separe refatoração de mudança de comportamento em PRs diferentes. Nada esconde mais um defeito do que 700 linhas de renomeação com três linhas de lógica no meio.
• Fatie por camada ou por etapa: migração de banco, depois backend, depois interface.
• Use feature flag para poder entregar meio caminho sem esperar o todo.
• Se o PR precisa ser grande (geração automática, upgrade de dependência), diga isso na descrição e aponte onde está a mudança que merece atenção.

Descrição importa: contexto, o que muda, como testar, o que não está no escopo. Quinze linhas de descrição economizam meia hora de quem revisa.

Automatize antes de pedir revisão humana

Nenhum minuto de pessoa deve ser gasto no que uma ferramenta resolve:

# no PR, antes de qualquer olho humano
- formatação (prettier, gofmt, black, terraform fmt)
- lint e análise estática
- testes e cobertura do diff
- verificação de segredo e dependências vulneráveis
- build do artefato

Discussão sobre vírgula e indentação em PR é sintoma de formatador ausente. Configure o formatador, aplique no repositório inteiro em um commit isolado, e o assunto acaba.

Comentário útil e comentário ruído

Um bom comentário diz o que, por quê e o quanto importa:

Bloqueante: aqui a query roda dentro do laço, o que faz N+1 com 200 pedidos. Dá para trazer com select_related antes do laço?

Sugestão (não bloqueia): talvez pedidos_pendentes fique mais claro que lista2.

Dúvida: se o gateway devolver 500, esse retry repete a cobrança?

Marcar a intensidade (bloqueante / sugestão / dúvida / elogio) resolve metade dos mal-entendidos: quem escreveu sabe o que precisa mudar antes do merge e o que é preferência.

O que evita atrito, na prática: comente o código, não a pessoa (“essa função faz duas coisas”, não “você complicou”); pergunte em vez de acusar quando não tiver certeza; aprove com comentários menores em vez de segurar o PR por preferência de estilo; e diga quando algo está bom — revisão só com crítica desgasta.

Aprovação condicional (“aprovo, ajusta o nome antes do merge”) desbloqueia sem perder o ponto. Use bastante.

Donos de código e obrigatoriedade

CODEOWNERS roteia a revisão para quem conhece a área — e, mal usado, cria gargalo:

# CODEOWNERS
/infra/            @empresa/plataforma
/servicos/checkout/ @empresa/time-loja
/.github/workflows/ @empresa/plataforma
*.tf               @empresa/plataforma

Cuidados: mais de um dono por caminho (pessoa sai de férias), revisão obrigatória apenas onde o risco justifica, e caminho de emergência documentado para incidente — com registro posterior, não com exceção silenciosa.

Meça o processo, não as pessoas

Duas métricas bastam: tempo até a primeira revisão e tempo total até o merge. Se a primeira passa de algumas horas, o problema é de fluxo (ninguém tem revisão como prioridade), não de esforço individual.

Nunca meça “comentários por revisor” ou “PRs revisados” — vira teatro na semana seguinte. A conversa útil é sobre o fluxo: PRs pequenos, revisão como primeira tarefa do dia, e automação carregando o que é mecânico.

Próximo passo: decida onde esse código mora em Monorepo e polirrepo.