Carregando
Code review de verdade vai muito alem de checar formatacao e naming conventions. Em sistemas criticos, um review mal feito pode custar vidas. Aqui estao as tecnicas que
Em junho de 1996, o Ariane 5 explodiu 37 segundos apos o lancamento. O bug estava em codigo reaproveitado do Ariane 4. Codigo que passou por anos de revisao e operacao bem-sucedida. O problema e que ninguem revisou as suposicoes do codigo antigo quando o contexto mudou.
Se voce quer a historia completa, leia <a href='/2025-3/a-historia-nao-contada-do-desa'>A Historia Nao Contada do Desastre do Ariane 5</a>. Aqui vou falar sobre o que um code review adequado teria capturado, e como estruturar reviews que realmente encontram bugs antes que causem dano.
Code review nao e so checar se o nome da variavel e descritivo. Em sistemas que importam, review e um processo de engenharia com tecnicas especificas, ferramentas e uma cultura que a maioria das equipes nao tem.
O codigo do sistema de navegacao inercial foi reutilizado do Ariane 4 sem revisao das suposicoes de negocio. A suposicao que quebrou: a velocidade horizontal do foguete nunca excederia 32.767 (o limite de um int16). No Ariane 4, isso era verdade. No Ariane 5, muito mais potente, nao era.
Um review que perguntasse 'quais sao as suposicoes de range desse codigo e elas ainda sao validas nesse contexto?' teria encontrado o problema. Um review que verificasse 'o que acontece quando esse valor excede o tipo?' teria encontrado o problema.
Mas a maioria dos reviews nao faz essas perguntas. Revisores olham para o codigo e perguntam 'isso parece razoavel?'. Codigo legado que funcionou por anos parece muito razoavel.
Code Review que Salva Vidas: Boas Praticas. Code review de verdade vai muito alem de checar formatacao e naming conventions. Em sistemas criticos, um review mal feito pode custar vidas. Aqui estao as tecnicas que fazem diferenca real.
Nao existe um unico tipo de code review. Diferentes tecnicas encontram diferentes tipos de problemas. Equipes que fazem so uma delas ficam cegas para categorias inteiras de bugs.
Esse e o review que todo mundo faz e acha que e suficiente. Formatacao, naming, documentacao. E o menos valioso para encontrar bugs serios, mas o mais facil de automatizar.
Regra de ouro: tudo que pode ser verificado automaticamente por uma ferramenta nao deve consumir tempo humano no review. Use linters, formatters e analisadores estaticos para esse nivel. Libere o revisor humano para pensar.
Aqui e onde a maioria das equipes para. O revisor le o codigo e pensa 'isso parece certo?'. E melhor que nada, mas depende muito da experiencia e atencao do revisor no momento.
O revisor ativamente tenta encontrar como o codigo pode falhar. Pensa como um atacante ou como Murphy: se algo pode dar errado, o que acontece? Esse nivel de review e o que diferencia equipes mediocres de equipes que produzem software confiavel.
Analise estatica examina o codigo sem executar. Encontra categorias inteiras de bugs que reviewers humanos frequentemente perdem porque o codigo 'parece certo'.
Testes de mutacao sao uma tecnica poderosa que a maioria das equipes nunca usou. A ideia e simples: introduza bugs intencionais no codigo e verifique se seus testes os detectam.
Se voce tem 90% de coverage mas seus testes nao detectam mutacoes simples como trocar '+' por '-' ou '<' por '<=', seus testes nao estao verificando a logica correta.
Ferramentas de mutation testing: Pitest para Java, Stryker para JavaScript/TypeScript, mutmut para Python, cargo-mutants para Rust. Integrar mutation testing no CI e um sinal claro que a equipe leva qualidade a serio.
Pair programming e o unico processo de desenvolvimento onde review acontece em tempo real. Um programador escreve, o outro revisa constantemente. Bugs sao capturados antes de existir no repositorio.
Estudos da Universidade de Utah mostram que pair programming reduz defeitos em 15% a 50% dependendo do dominio, com custo de tempo adicional de 15% (nao 100% como muitos supõem). Para sistemas criticos, essa troca e muito favoravel.
Checklists existem por uma razao: pilotos de aviao usam checklists antes de cada voo nao porque sao ruins, mas porque a memoria humana e falha e checklists compensam isso. O mesmo vale para code review.
Correcao: o codigo faz o que a especificacao diz? Para todos os inputs possiveis?
Casos de borda: null, vazio, zero, valores negativos, valores no limite do tipo, concorrencia.
Tratamento de erro: todos os caminhos de erro sao tratados? O sistema falha de forma segura?
Suposicoes: quais suposicoes o codigo faz? Essas suposicoes sao validas e documentadas?
Seguranca: ha inputs que podem ser controlados por usuarios externos? Validacao presente?
Performance: ha loops aninhados, queries N+1, ou operacoes O(n^2) em caminhos quentes?
Testabilidade: o codigo e testavel? Existem testes adequados para o novo comportamento?
Para sistemas com requisitos de seguranca formal (aviacao, medicina, automotivo), o checklist e muito mais extenso e o processo inclui geralmente duas ou mais revisoes independentes por pessoas que nao tiveram contato previo com o codigo.
Tecnicas e ferramentas sao o facil. A parte dificil de code review e cultural. Times que tem medo de conflito fazem review superficial. Times competitivos usam review para mostrar que sabem mais que o autor. Nenhum dos dois funciona.
Review saudavel pressupoe que bugs sao inevitaveis e o objetivo e encontra-los antes que causem dano, nao atribuir culpa. O codigo que e revisado pertence a equipe, nao ao autor. Comentarios sao sobre o codigo, nunca sobre a pessoa.
O Ariane 5 falhou em parte porque a cultura de reusar codigo proven era mais forte que a cultura de questionar suposicoes. Um time que pergunta 'por que isso funciona?' em vez de 'isso parece certo?' teria feito as perguntas certas. A historia completa em <a href='/2025-3/a-historia-nao-contada-do-desa'>A Historia Nao Contada do Desastre do Ariane 5</a> mostra como decisoes culturais e organizacionais contribuiram tanto quanto o bug tecnico.
Bugs que custaram bilhões
Em sistemas criticos como avionics, defesa e medicina, review informal nao e suficiente. A industria usa review formal com checklists estruturados, multiplos revisores independentes, e em alguns casos verificacao matematica via model checking ou SPARK.
Ferramentas encontram: null dereferences, resource leaks, integer overflows, race conditions obvias, SQL injection, XSS.
Ferramentas NAO encontram: logica de negocio incorreta, suposicoes invalidas sobre o dominio, comportamento emergente em sistemas distribuidos, casos de borda especificos do produto.