Cada Camada de Revisão Deixa Seu Time Mais Lento

Uma startup envia um bug para produção. A resposta da gestão: exigir revisão de código. Outro bug escapa. Resposta: exigir dois revisores. Depois, um incidente de segurança. Resposta: adicionar uma etapa de revisão de segurança. Depois, uma inconsistência de design. Resposta: adicionar uma revisão de design. Em dois anos, toda mudança, por menor que seja, passa por quatro etapas de revisão, leva três dias para ser mesclada, e os desenvolvedores que antes entregavam todo dia agora gastam mais tempo revisando código do que escrevendo.

Esse padrão é tão comum que quase virou uma lei do comportamento organizacional: cada incidente cria uma nova camada de revisão, e nenhuma camada de revisão é removida. O resultado é um processo que otimiza para evitar o último incidente ao custo de impedir todo o progresso futuro.

A Matemática das Filas de Revisão

Cada camada de revisão não é apenas aditiva, ela é multiplicativa. Se uma única revisão leva em média 4 horas para ser concluída (não a revisão em si, que leva 20 minutos, mas o tempo que o PR fica parado na fila esperando um revisor pegá-lo), então duas revisões sequenciais levam 8 horas. Três levam 12. Quatro levam 16.

Mas é pior que isso, por causa da troca de contexto. O desenvolvedor envia um PR e começa outro trabalho. Quando o feedback chega horas depois, ele precisa voltar ao trabalho antigo, recarregar o contexto, ajustar o código e enviar de novo, e então esperar mais. Cada rodada de revisão custa de 30 a 60 minutos de overhead de troca de contexto, além do tempo na fila.

E há o efeito cascata. Se o revisor A pede mudanças, o desenvolvedor as ajusta e reenvia. Agora o revisor B (que ainda não viu o PR) revisa e pede outras mudanças. O desenvolvedor ajusta essas também. Agora o revisor A precisa revisar de novo para confirmar que o feedback foi atendido, mas ele já foi para outras tarefas e o PR voltou para a fila.

Timeline of a PR through a 3-reviewer process:
Day 1 9:00  — Developer submits PR
Day 1 14:00 — Reviewer A reviews, requests changes
Day 1 15:00 — Developer addresses feedback, resubmits
Day 2 10:00 — Reviewer B reviews, requests different changes
Day 2 11:00 — Developer addresses, resubmits
Day 2 16:00 — Reviewer A re-reviews, approves
Day 3 11:00 — Reviewer C reviews, approves
Day 3 11:30 — Reviewer B re-reviews, approves
Day 3 12:00 — PR merges
Elapsed time: ~3 business days
Actual review time: ~90 minutes total
Actual code change time: ~2 hours
Time waiting in queues: ~22 hours
Queue time is 80% of the total elapsed time.

O Paradoxo da Qualidade

A premissa por trás de adicionar camadas de revisão é que mais revisão produz código melhor. Isso é verdade até certo ponto, e depois se inverte.

Um revisor atento encontra problemas reais: erros de lógica, casos extremos esquecidos, falhas de segurança, questões de design de API. Um segundo revisor eventualmente pega algo que o primeiro deixou passar, talvez 10 a 20% das vezes. Um terceiro quase nunca encontra algo que os dois primeiros não acharam. O valor marginal de cada revisor adicional cai bruscamente.

Enquanto isso, o custo de qualidade de merges lentos é real e não é contabilizado. Branches de longa duração divergem da main, exigindo rebases que introduzem erros de merge. Os desenvolvedores agrupam mais mudanças em cada PR para evitar o overhead de revisão por PR, tornando cada um maior e mais difícil de revisar com cuidado. Revisores sofrem com fadiga: quando a fila tem 15 PRs, você passa o olho em vez de ler com atenção.

O paradoxo: adicionar camadas de revisão para melhorar a qualidade pode, na prática, reduzir a qualidade, porque cria incentivos (PRs maiores, revisões apressadas, branches desatualizadas) que minam o próprio processo de revisão.

O Que os Processos Pesados de Revisão Realmente Evitam

Processos de revisão costumam ser justificados por incidentes específicos. "Enviamos um bug porque ninguém revisou o código." Mas perguntar se a revisão teria pego um bug específico é diferente de perguntar se a exigência de revisão melhora os resultados como um todo.

Estudos sobre a eficácia da revisão de código encontram de forma consistente que ela pega cerca de 60% dos defeitos, a maioria em problemas superficiais como nomenclatura, formatação e erros de lógica óbvios. Bugs arquiteturais profundos, problemas de concorrência e vulnerabilidades de segurança raramente são pegos na revisão, porque exigem entender o sistema inteiro, não apenas o diff. Os bugs que causam incidentes em produção são desproporcionalmente do tipo que a revisão não pega.

O que realmente previne incidentes em produção são testes, monitoramento e a capacidade de fazer deploy e rollback rapidamente. Um time que entrega rápido, com bons testes, feature flags e rollbacks instantâneos, terá menos incidentes do que um time com quatro camadas de revisão, mas sem testes de integração e com ciclos de deploy de uma hora.

A Quantidade Certa de Revisão

Revisão de código tem valor. Um revisor por PR, com expectativas claras sobre o que ele deve verificar, é o ponto ideal para a maioria dos times. Veja como isso funciona na prática.

• Um revisor, não dois ou três. O primeiro revisor pega 80% do que a revisão vai pegar. O segundo adiciona valor marginal a um custo significativo. Reserve processos com múltiplos revisores para mudanças realmente de alto risco (migrações de banco de dados, mudanças de autenticação, alterações em APIs públicas).
• Limite o tempo da fila de revisão. Se um PR não foi revisado em 4 horas, isso é uma falha do processo, não um problema de revisor preguiçoso. O time precisa priorizar a capacidade de revisão ou aceitar que tem mais desenvolvedores do que o processo consegue suportar.
• PRs pequenos, não grandes. Um PR de 50 linhas recebe uma revisão cuidadosa em 10 minutos. Um PR de 500 linhas recebe uma revisão superficial em 30 minutos. O PR de 50 linhas é revisado melhor, mesmo com menos tempo. Limites de tamanho (200 a 300 linhas no máximo) melhoram a qualidade da revisão mais do que adicionar revisores.
• Pule a revisão para mudanças de baixo risco. Mudanças de configuração, atualizações de texto, bumps de dependências, adição de testes: nada disso exige o mesmo rigor de mudanças na lógica de negócio. Defina uma categoria de "baixo risco" e permita self-merge com revisão pós-merge.
• Automatize o que as máquinas fazem melhor. Linting, formatação, checagem de tipos, cobertura de testes: são tarefas de revisão que máquinas executam mais rápido e de forma mais consistente que humanos. Não desperdice a atenção do revisor com coisas que um check de CI já resolve.

O Problema Cultural

Reduzir camadas de revisão é difícil porque parece reduzir a segurança. Ninguém quer ser a pessoa que defendeu menos revisão logo antes de um incidente em produção. Isso é um problema de cultura organizacional, não técnico.

A forma de pensar que ajuda: a revisão é um dos muitos mecanismos de segurança, e tem retornos decrescentes. Adicionar um quarto revisor para prevenir bugs é como adicionar um quarto cadeado para evitar roubo: o primeiro cadeado faz quase todo o trabalho, e cada cadeado extra gera inconveniência sem segurança proporcional. Ninguém usa quatro cadeados. Não coloque quatro revisores.

Times que entregam rápido e quebram menos tendem a investir nos mecanismos que realmente previnem incidentes: testes automatizados abrangentes, feature flags para liberação gradual, monitoramento robusto com alertas, rollbacks em um clique e uma cultura sem culpa, que trata incidentes como oportunidades de aprendizado e não como alvos de culpa. Esses investimentos se acumulam ao longo do tempo de um jeito que as camadas de revisão não fazem.

Removendo uma Camada de Revisão

Se o seu time acumulou exigências de revisão demais, veja como reduzi-las sem causar pânico.

Comece medindo o processo atual. Quanto tempo leva um PR da submissão até o merge? Quanto desse tempo é espera na fila e quanto é revisão ativa? Quantos PRs estão na fila de revisão a qualquer momento? Esses números tornam o custo visível. A maioria dos times fica chocada ao descobrir que o PR médio leva 3 dias para ser mesclado.

Depois, faça um experimento. Por um mês, exija um revisor em vez de dois. Acompanhe as mesmas métricas. A taxa de incidentes mudou? A qualidade do código (medida por taxa de defeitos, não por achismo) mudou? Quase sempre, a resposta é: os incidentes não aumentaram, a qualidade se manteve e a vazão melhorou significativamente.

O objetivo não é zero revisão, e sim a revisão mínima que mantém a qualidade e maximiza a vazão. Esse mínimo quase sempre é menor do que o que os times fazem hoje, porque as camadas de revisão se acumulam com a resposta a incidentes, mas nunca são removidas pela otimização de processos. Como em quase tudo em construir software de qualidade, a resposta não é mais processo, e sim o processo certo.