Code Review que Pega Bug de Verdade: Checklist

90% dos code reviews sao teatro

Vou ser direto: a maioria dos code reviews no mercado nao serve pra nada. O dev abre o PR, olha por 3 minutos, deixa um comentario sobre nome de variavel ou indentacao, marca approved e segue com a vida. Enquanto isso, um overflow silencioso ou uma race condition passa batido e vai pra producao.

Estudos da Microsoft Research mostram que reviews eficazes demoram entre 60 e 90 minutos por 200-400 linhas de codigo. Se voce ta revisando 2000 linhas em 15 minutos, voce nao ta revisando — ta fingindo. E ta tudo bem admitir isso. O primeiro passo pra melhorar e reconhecer que o processo atual nao funciona.

O problema real e que code review virou ritual. Algo que o time faz porque 'e boa pratica', nao porque acredita que vai encontrar bugs. E quando voce faz algo so por obrigacao, o resultado e proporcional ao esforco investido: zero.

Entao como transformar code review de teatro em algo que realmente protege o codigo? Dividindo em niveis. Nem todo PR precisa do mesmo nivel de scrutinio. Um fix de typo nao precisa da mesma atencao que uma mudanca no calculo de pagamento.

Nivel 1: O basico que deveria ser automatizado

Nivel 1 e tudo que maquina faz melhor que humano. Se seu time ainda perde tempo de review checando formatacao, nomes de variavel ou imports nao usados, voce ta desperdicando capital humano em trabalho de linter.

Quando nivel 1 ta automatizado, o reviewer humano pode focar no que realmente importa: logica, premissas e edge cases. E ai que comeca o trabalho de verdade.

Nivel 2: Edge cases e limites

Nivel 2 e onde voce comeca a pensar como um atacante ou como Murphy. O que pode dar errado? Quais sao os valores limites? O que acontece quando o input e null, vazio, negativo, gigantesco ou no formato errado?

O Ariane 5 teria sobrevivido se alguem no review tivesse perguntado: 'e se o valor de velocidade horizontal for maior que 32.767?' O Boeing 737 MAX teria sido diferente se alguem perguntasse: 'e se o sensor de angulo de ataque der leitura errada?' Essas perguntas parecem obvias em retrospectiva. O desafio e fazer elas antes do desastre.

Nao precisa responder todas pra todo PR. Mas quanto mais critico o codigo (pagamentos, autenticacao, dados de usuario), mais perguntas precisam de resposta. O reviewer nao precisa testar — precisa verificar que o autor pensou nesses cenarios e tem cobertura pra eles.

Nivel 3: Premissas de negocio e contexto

Nivel 3 e o mais dificil e o mais valioso. E onde voce questiona nao o codigo em si, mas as suposicoes por tras dele. O Ariane 5 nao tinha um bug de codigo — tinha uma premissa errada. O codigo funcionava perfeitamente no Ariane 4. A premissa de que 'os valores de velocidade horizontal nunca excedem X' e que estava errada no novo contexto.

Perguntas de nivel 3 sao do tipo: 'esse modulo que estamos reutilizando foi feito pra quais condicoes?' ou 'o que muda se o volume de usuarios triplicar?' ou 'essa integracao assume que o servico externo sempre responde em menos de 2 segundos — isso e verdade?'

Nivel 3 exige que o reviewer entenda o contexto do projeto, nao so o diff do PR. Por isso funciona melhor quando o reviewer mais senior faz as perguntas e o autor explica o raciocinio. Se o autor nao consegue explicar por que fez de certo jeito, isso ja e um sinal de alerta.

Implementando sem burocracia

Sei o que voce ta pensando: 'legal, mas meu time ja reclama que review demora muito, imagina com tudo isso.' Justo. A chave e nao aplicar os 3 niveis em todo PR. Categorize os PRs e aplique o nivel adequado.

O objetivo nao e transformar todo review numa auditoria de 2 horas. E garantir que os PRs que realmente podem causar estrago recebam atencao proporcional ao risco. O resto pode ser rapido e leve.