Code Review que Salva Vidas: Boas Praticas

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 Historia Nao Contada do Desastre do Ariane 5. 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 Que o Review do Ariane 5 Nao Fez

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.

Os Niveis de Code Review

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.

Nivel 1: Review de estilo e convencao

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.

Nivel 2: Review de logica e correcao

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.

Nivel 3: Review adversarial

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.

Nivel 4: Review formal e verificacao

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.

Analise Estatica: Seu Revisor Automatico 24/7

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: Medindo a Qualidade dos Testes

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.

// Codigo original
function calculateDiscount(price: number, isPremium: boolean): number {
    if (isPremium && price > 100) {
        return price * 0.9;  // 10% desconto
    }
    return price;
}

// Mutante 1: operador logico trocado
// if (isPremium || price > 100)  <- teste deveria detectar isso

// Mutante 2: operador de comparacao trocado
// if (isPremium && price >= 100)  <- teste deveria detectar isso

// Mutante 3: constante trocada
// return price * 0.8;  <- teste deveria detectar isso

// Se seus testes nao matam esses mutantes, o coverage e uma ilusao.

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 como Review Continuo

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.

Quando pair programming faz mais sentido

O Checklist de Review para Software Critico

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.

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.

A Cultura Por Tras do Review

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 Historia Nao Contada do Desastre do Ariane 5 mostra como decisoes culturais e organizacionais contribuiram tanto quanto o bug tecnico.