Code Review em Sistemas Criticos: Checklist

Galera, vou ser direto: 90% dos code reviews que acontecem no mercado sao teatro. O dev abre o PR, olha por 5 minutos, deixa um comentario sobre indentacao, marca approved e vai almocar. Enquanto isso, um overflow silencioso, uma race condition ou uma premissa invalida passam direto pra producao.

Esse artigo e um checklist de 5 fases pra code review que realmente previne desastres. Nao inventei essas fases — elas vem de analise pos-mortem de bugs que custaram vidas e bilhoes de dolares.

Por que review normal nao basta

O review tipico foca no que e facil de ver: nomenclatura, formatacao, complexidade superficial. Isso e util, mas nao pega os bugs que realmente importam. Os bugs que derrubam sistemas estao em premissas invalidas, condicoes de borda nao testadas e interacoes entre modulos que ninguem olhou.

Estudo da Microsoft Research: reviews eficazes demoram entre 60 e 90 minutos por 200-400 linhas. Se voce revisa 2000 linhas em 15 minutos, nao ta revisando — ta dando carimbo.

O outro problema: revisores olham pro codigo e perguntam 'isso parece certo?'. Codigo que ja funcionou antes parece muito certo. O codigo do Ariane 4 que derrubou o Ariane 5 'parecia certo' porque tinha funcionado por anos. Review precisa perguntar 'isso funciona nesse contexto?' — pergunta completamente diferente.

Fase 1: Tipos e Boundaries

A primeira fase checa se os dados cabem nos recipientes. E aqui que voce pega overflow, truncation e erros de conversao.

Teria pego o Ariane 5? Sim. A conversao de float64 pra int16 sem checagem de range seria flagrada no item 2.

Fase 2: Concorrencia e Timing

Race conditions sao os bugs mais dificeis de encontrar em review porque o codigo 'parece funcionar' — e funciona, 99.9% das vezes. O 0.1% e quando mata gente (Therac-25).

Teria pego o Therac-25? Sim. A race condition entre o teclado do operador e a atualizacao do colimador seria flagrada nos itens 1 e 2.

Fase 3: Tratamento de Erros

A pergunta aqui nao e 'o happy path funciona?' — e 'o que acontece quando da errado?'. Porque vai dar errado.

Teria pego o Ariane 5 de novo? Sim. A excecao de overflow nao era tratada — o sistema simplesmente desligava em vez de entrar em modo seguro.

Fase 4: Edge Cases e Premissas

Essa e a fase mais importante e a menos feita. Aqui voce questiona as premissas implicitas do codigo — as coisas que o autor assumiu como verdade e nao documentou.

Teria pego o Mars Climate Orbiter? Sim. Item 6 — unidades inconsistentes entre o modulo da Lockheed Martin e o da NASA. Teria pego o Ariane 5? Sim. Item 2 — codigo reutilizado sem revisao de premissas.

Fase 5: Compatibilidade e Integracao

A ultima fase olha pra como o codigo interage com o mundo externo: outros modulos, APIs, banco de dados, sistema operacional.

Teria pego a Knight Capital? Sim. Item 4 — a feature flag reutilizada sem limpeza do codigo legado seria flagrada.

CI/CD como gate obrigatorio de review

Checklist humano e bom, mas gente esquece. O ideal e automatizar tudo que da pra automatizar no CI/CD e deixar o humano focado no que maquina nao pega: logica de negocio e premissas.

Num mundo perfeito, nenhum PR vai pra producao sem passar por analise estatica, testes automatizados e staged rollout. Na pratica, comece com o que der e va adicionando gates com o tempo.

Ferramentas de analise estatica por linguagem

Cultura de review que funciona

Checklist e ferramenta sao metade da equacao. A outra metade e cultura. Se o time trata review como obrigacao chata que atrasa o sprint, nenhum checklist vai funcionar.

Nas equipes que produzem software confiavel, review e tratado como a atividade de maior valor do dia. Encontrar um bug em review custa 10x menos que encontrar em QA e 100x menos que encontrar em producao. Isso nao e exagero — e dado da IBM System Sciences Institute.

Template de review pra copiar

Copie e cole esse template no seu PR template do GitHub. Ele forca o revisor a pensar em cada fase antes de aprovar:

## Review Checklist

### Tipos e Boundaries
- [ ] Tipos adequados ao range do dominio
- [ ] Conversoes de tipo validadas com valores extremos
- [ ] Aritmetica checada contra overflow

### Concorrencia
- [ ] Recursos compartilhados protegidos
- [ ] Sem TOCTOU
- [ ] Timeouts definidos

### Erros
- [ ] Falha segura (fail-safe)
- [ ] Recursos liberados em todos os paths
- [ ] Logs com contexto

### Premissas
- [ ] Premissas do codigo documentadas e validas nesse contexto
- [ ] Edge cases testados (null, vazio, max, negativo)

### Integracao
- [ ] Backward-compatible
- [ ] Feature flags limpas
- [ ] Deploy gradual possivel

Simples assim. Nao precisa de ferramenta cara nem de processo complicado. Precisa de disciplina pra checar cada item em cada PR. Os desastres que mostramos nesse artigo teriam sido evitados com checklists menos completos que esse.

Perguntas frequentes

Esse checklist e so pra sistemas criticos?

As 5 fases se aplicam a qualquer software. Claro, em sistemas criticos o rigor e maior — voce nao pode aprovar sem cobrir todos os itens. Em um SaaS comum, nem todo item se aplica a todo PR. Mas os principios (checar tipos, concorrencia, erros, premissas e integracao) valem pra qualquer projeto.

Analise estatica substitui code review humano?

Nao. Ferramentas encontram bugs mecanicos: null dereference, resource leaks, overflow obvio. Ferramentas nao encontram: logica de negocio incorreta, premissas invalidas sobre o dominio, decisoes de design ruins. Voce precisa dos dois.

Como convencer o time a adotar esse processo?

Mostre o custo de nao fazer. Um bug em producao custa 100x mais que um bug encontrado em review (dado IBM). Comece pequeno: adicione o template de checklist no PR template e peca que cada revisor marque os itens. A mudanca de cultura vem com o tempo.