Code review tem dois destinos possíveis num time: virar a prática que mais eleva a qualidade e espalha conhecimento, ou virar o gargalo onde pull requests envelhecem e rivalidades nascem. A diferença está em algumas regras simples que a maioria ignora.

O Google, que revisa praticamente cada linha que entra no seu monorepo, publica abertamente suas práticas de engenharia (google.github.io/eng-practices). Combinando essas referências com o que vemos funcionar em times menores, este é o manual honesto.

Por que revisar (não é só para achar bug)

Estudos clássicos da indústria, como os conduzidos pela SmartBear com a Cisco, mostram que revisões encontram defeitos cedo e de forma barata, mas o retorno vai além:

• Conhecimento espalhado: cada review é uma aula em contexto real. O código deixa de ter dono único, e as férias de alguém deixam de ser um risco operacional.
• Padrão de código vivo: convenções se propagam por osmose, não por documento morto.
• Design melhor: saber que alguém vai ler força clareza. O primeiro leitor do seu código é o revisor; o segundo é você mesmo, seis meses depois.

As regras que destravam o fluxo

1. PR pequeno ou nada. A pesquisa da SmartBear apontou que a eficácia da revisão despenca depois de ~400 linhas (smartbear.com). PR de 2 mil linhas recebe "LGTM" no cansaço, que é o oposto de revisão. Fatie por comportamento entregável; se a feature é grande, a revisão acompanha o fatiamento.

2. Revisão é prioridade, não sobra. O padrão do Google: responder reviews em no máximo um dia útil. PR parado bloqueia o autor, apodrece com conflitos e atrasa o sprint inteiro. Regra prática que adotamos: revisar antes de começar tarefa nova.

3. Máquina primeiro, humano depois. Lint, formatação, testes e build rodam no CI antes de qualquer olho humano. Revisor discutindo indentação é desperdício de senioridade; a máquina não se constrange em apontar vírgula.

4. O autor prepara o terreno. Descrição com o porquê, o que mudou e como testar. Auto-revisão antes de pedir a dos outros (metade dos problemas o próprio autor acha ao reler). Respeito pelo tempo de quem revisa é meio caminho para reviews rápidos.

5. Comente sobre o código, nunca sobre a pessoa. "Esse método pode receber null aqui" em vez de "você esqueceu o null de novo". Prefixe sugestões opcionais com "nit:" para separar o obrigatório do gosto pessoal. E elogie o que está bom: review não é só caçada de erro.

6. Aprove o "melhor que ontem", não o perfeito. A régua do Google é explícita: aprova-se a mudança que melhora a saúde geral do código, mesmo que não seja ideal. Perfeccionismo de revisor é a forma mais educada de travar um time.

7. Discordou duas vezes? Sai do PR. Thread de 15 comentários é sinal de que a conversa deveria ser uma chamada de 5 minutos. Resolve-se falando, registra-se a conclusão no PR.

O que o review NÃO deve ser

• Gate de poder: revisor único que "libera" tudo cria gargalo e feudo. Conhecimento compartilhado pede revisores rotativos.
• Substituto de pairing e mentoria: feedback profundo de arquitetura merece conversa antes do código, no desenho do contrato ou da solução, não depois de 800 linhas prontas.
• Teatro: aprovação automática por amizade ou pressa desliga o valor todo. Se o time não tem tempo para revisar, tem um problema de capacidade, não de processo.

Métricas que valem o acompanhamento

Tempo até a primeira resposta, tamanho médio dos PRs e idade dos PRs abertos. Três números que contam se o fluxo está saudável. O que não vale: contar comentários por revisor, que só incentiva picuinha.

Essa mecânica de fluxo (PRs pequenos, CI na frente, resposta rápida) é parte do que instalamos nos times no nosso serviço de Desenvolvimento Web, Mobile e Desktop, junto com a esteira que faz a revisão custar minutos, não dias.

Quer um raio-X do seu fluxo de review? Conte para a IA da Rabelo Digital, aqui no canto da tela, o tamanho médio dos seus PRs e quanto tempo esperam. Ela devolve o diagnóstico. Sem formulário, sem espera.

---

Leia também

• Web vs Mobile vs Desktop: quando escolher cada um
• API First: como pensar antes de codar
• Performance front-end: do zero ao avançado