Code Review Salva Vidas: Como Revisar Codigo
Na web, um bug no code review vira um ticket de hotfix. Na aviação, vira uma investigação de acidente com 200 mortos. As técnicas de revisão que a
TL;DR
Code Review Salva Vidas: Como Revisar Codigo. Na web, um bug no code review vira um ticket de hotfix. Na aviação, vira uma investigação de acidente com 200 mortos. As técnicas de revisão que a indústria aeronáutica usa podem transformar qualquer processo de review.
Eu faço code review todo dia. Abro o PR, leio o diff, checo se a lógica faz sentido, se os nomes estão bons, se tem teste. Aprovo ou peço mudanças. O ciclo inteiro leva entre 15 minutos e uma hora. Na maioria das vezes funciona bem.
Mas e quando o código que você está revisando controla o sistema de frenagem de um carro? Ou a dosagem de radiação numa máquina de radioterapia? Ou o piloto automático de um avião com 200 passageiros? O review de 15 minutos que funciona pra um CRUD não serve pra esses cenários. Nem de longe.
Eu mergulhei nas práticas de code review da aviação, medicina e automotivo pra entender o que eles fazem de diferente. E posso dizer: tem muita coisa que dá pra trazer pro nosso mundo web/mobile sem complicar o processo.
Por que code review comum não basta para sistemas críticos
O code review que fazemos em startups e empresas de tecnologia é informal por natureza. Você abre um PR, alguém olha, comenta, aprova. O foco é manter qualidade e consistência do código. Se passar um bug, a gente corrige em produção em minutos. Ninguém morre.
Em sistemas críticos, o custo de um bug que escapa do review pode ser medido em vidas humanas. O Therac-25 matou pacientes porque ninguém revisou o código de uma pessoa só. O Boeing 737 MAX matou 346 pessoas porque o MCAS foi aprovado sem escrutínio adequado. A equação muda completamente quando as consequências são irreversíveis.
Code Review Web/Mobile
O processo padrão na maioria das empresas de tecnologia
+ Prós
- • Rápido — ciclo de feedback em minutos ou horas
- • Flexível — cada time adapta o processo
- • Foco em legibilidade e manutenção do código
- • Bugs em produção são corrigíveis em minutos
− Contras
- • Revisores podem aprovar sem ler em profundidade
- • Sem checklist padronizado na maioria dos times
- • Pressão de deadline frequentemente encurta o review
- • Não verifica conformidade com normas de segurança
Code Review Sistemas Críticos
O processo usado em aviação, medicina e automotivo
+ Prós
- • Checklists obrigatórios com critérios objetivos
- • Independência total — quem escreve nunca revisa seu próprio código
- • Rastreabilidade completa entre requisito e código
- • Análise estática automatizada como pré-requisito
− Contras
- • Lento — um review pode levar dias ou semanas
- • Caro — exige pessoas dedicadas e ferramentas pagas
- • Burocrático — documentação extensiva obrigatória
- • Pode parecer desproporcional para código simples
O padrão DO-178C: como a aviação faz code review
O DO-178C (Software Considerations in Airborne Systems and Equipment Certification) é o padrão que define como software de aviação deve ser desenvolvido e verificado. Se você quer que seu software voe num avião comercial, tem que seguir esse documento. Não é sugestão — é obrigação legal.
O DO-178C define cinco níveis de criticidade, de A (catastrófico — falha causa crash do avião) a E (sem efeito na segurança). O nível de rigor do review aumenta com a criticidade. Para nível A, o código precisa de review independente — ou seja, a pessoa que revisa não pode ter participado de nenhuma forma no desenvolvimento daquele código.
Mas não para aí. O DO-178C exige rastreabilidade bidirecional. Cada linha de código precisa estar ligada a um requisito. Cada requisito precisa estar ligado ao código que o implementa. Se tem código sem requisito: problema. Se tem requisito sem código: problema. Se tem código que não foi testado: problema. Tudo é rastreado, tudo é documentado.
- Cada requisito de software é documentado individualmente com ID rastreável
- O código é escrito para implementar exatamente aqueles requisitos — nada mais, nada menos
- Um revisor independente verifica se o código atende cada requisito listado
- Testes são escritos para cada requisito e executados com cobertura MC/DC para nível A
- A rastreabilidade bidirecional é verificada: requisito → código → teste → resultado
- Toda a evidência de review é documentada e arquivada para auditoria futura
O princípio da independência no review
Esse é o conceito mais poderoso que a aviação trouxe pro mundo do software: independência. Em nível A do DO-178C, quem verifica o código não pode ter escrito, ajudado a escrever, nem orientado quem escreveu. É independência total.
A lógica é simples. Se eu escrevo um código, meu cérebro já modelou a solução de uma forma. Quando eu leio meu próprio código, eu leio o que eu quis escrever, não o que está escrito. Os mesmos vieses que me levaram a criar o bug me impedem de enxergá-lo na revisão. Outro cérebro, sem contexto prévio, olha o código com olhos frescos e pega coisas que o autor jamais pegaria.
Na prática web, a gente meio que faz isso — outra pessoa revisa o PR. Mas a diferença é o rigor. Na aviação, a independência é verificada formalmente. Na web, frequentemente o reviewer é o colega do lado que 'dá uma olhada rápida' entre duas reuniões. Não é a mesma coisa.
Checklist de review para código crítico
Montei esse checklist baseado nas práticas de DO-178C, IEC 62304 (medical) e ISO 26262 (automotivo), adaptado pra linguagem e contexto de desenvolvimento moderno. Não precisa seguir tudo em todo review — mas se o código lida com dados sensíveis, transações financeiras ou saúde de usuários, vale usar.
Checklist de review: segurança e edge cases
- Todas as entradas do usuário são validadas no backend, independente do que o frontend faz?
- Existe proteção contra integer overflow em cálculos com valores externos?
- Ponteiros e referências são verificados contra null/undefined antes de uso?
- Recursos (conexões, file handles, locks) são sempre liberados, mesmo em caso de exceção?
- Operações concorrentes estão protegidas contra race conditions?
- Timeouts estão configurados em todas as chamadas externas (APIs, banco, filas)?
- Dados sensíveis (senhas, tokens, PII) nunca aparecem em logs?
- A lógica de retry tem backoff exponencial e limite máximo de tentativas?
- Inputs com tamanho extremo (strings gigantes, arrays com milhões de itens) são tratados?
- A funcionalidade falha de forma segura (fail-safe) quando algo inesperado acontece?
Checklist de review: lógica e rastreabilidade
Checklist de review: lógica e rastreabilidade
- Cada bloco de código está vinculado a um requisito ou user story identificável?
- A lógica de negócio corresponde exatamente ao que foi especificado?
- Existe código morto (dead code) que deveria ter sido removido?
- Os testes cobrem o caminho feliz e pelo menos 3 edge cases por função?
- As mensagens de erro são descritivas sem expor informação interna do sistema?
- O código trata todos os estados possíveis de uma enum/switch (incluindo default)?
- Comparações de ponto flutuante usam tolerância em vez de igualdade exata?
Ferramentas de análise estática que pegam o que olho humano não pega
Review humano é insubstituível para lógica de negócio e design. Mas pra certos tipos de bug, ferramentas de análise estática são objetivamente superiores. Elas não cansam, não têm viés, e checam cada linha de código contra centenas de regras simultaneamente.
MISRA C/C++
Conjunto de regras para C e C++ usado na indústria automotiva e aeroespacial. Proíbe construções perigosas como ponteiros selvagens e casts implícitos.
Coverity
Análise estática da Synopsys que encontra bugs de concorrência, null dereference, buffer overflow e resource leaks em C, C++, Java e C#.
Polyspace
Da MathWorks. Prova matematicamente que partes do código não têm certos tipos de bug. Usado em automotivo e aeroespacial.
SonarQube
O mais popular para web. Encontra code smells, vulnerabilidades e bugs em dezenas de linguagens. Versão open source disponível.
Semgrep
Análise estática moderna e rápida. Regras customizáveis em YAML. Ótimo para enforcement de padrões de segurança em CI.
O ideal é rodar análise estática automaticamente no CI, antes do review humano. Assim o reviewer não perde tempo com coisas que uma ferramenta pega sozinha — foca na lógica, no design e nas decisões de arquitetura.
Cultura de segurança vs cultura de velocidade
Esse é o ponto que separa organizações que produzem software seguro de organizações que produzem software rápido. Na aviação, ninguém pressiona um engenheiro a aprovar review mais rápido. Ninguém diz 'a gente precisa shipar esse MCAS até sexta, dá um approve aí'. Se um reviewer não está confortável, o código não vai. Fim.
Na cultura de startups, a pressão é o oposto. Ship fast, break things. Move fast. O code review é visto como gargalo, não como proteção. Reviewers sentem pressão social pra aprovar rápido — principalmente quando o PR é do tech lead ou de alguém sênior.
Não estou dizendo que toda empresa precisa virar a NASA. Mas se o seu software lida com dinheiro, saúde ou dados pessoais, a cultura precisa dar espaço pro reviewer dizer 'não está pronto' sem medo de represálias. Isso não é burocracia. É responsabilidade profissional.
Sinais de que seu review está virando formalidade
PRs são aprovados em menos de 5 minutos independente do tamanho.
Reviewers comentam 'LGTM' sem deixar nenhum comentário específico.
A métrica de sucesso do review é velocidade de aprovação, não qualidade.
Ninguém bloqueia PR de pessoas sêniores ou líderes técnicos.
Reviews são feitos no final do dia quando todo mundo já está cansado.
O que dá pra trazer pro mundo web
Não precisa implementar DO-178C completo no seu projeto Next.js. Mas dá pra adotar os princípios sem o peso da burocracia. Aqui está o que eu peguei da aviação e aplico nos meus projetos web.
- Tenha um checklist de review — mesmo que simples. Tira a subjetividade e garante que ninguém esquece de checar validação de input
- Rode análise estática no CI antes do review humano — SonarQube ou Semgrep no plano gratuito já resolve
- Nunca aprove seu próprio PR — parece óbvio, mas muita empresa aceita isso e é a raiz de muitos bugs
- Reserve tempo real para review — não é coisa pra fazer entre reuniões. Bloque 30 minutos no calendário
- Dê contexto no PR — descrição clara, prints do antes/depois, link pro ticket. Reviewer sem contexto aprova no automático
- Teste os edge cases que o autor pode não ter pensado — é ali que mora o bug que vai te acordar às 3 da manhã
Review como ferramenta de aprendizado
Um efeito colateral muito bom de fazer review com qualidade: os devs do time aprendem uns com os outros. Quando eu comento num PR explicando por que uma abordagem pode causar race condition, o autor aprende a evitar aquilo no futuro. Quando alguém comenta no meu PR apontando uma forma mais eficiente de resolver algo, eu levo aquilo pra vida.
Na aviação, a cultura de compartilhar erros é institucionalizada. Quando um quase-acidente acontece, ele é documentado e compartilhado com toda a indústria pra que todo mundo aprenda. Não é pra punir — é pra prevenir. Code review pode ter a mesma função no time de desenvolvimento.
Quando investir mais pesado no review
Nem todo código merece review de nível aeronáutico. Se você está mudando a cor de um botão, um 'LGTM' rápido é razoável. Mas tem momentos específicos onde vale gastar tempo de verdade no review.
Quando o review precisa ser rigoroso
- Código que lida com autenticação, autorização ou permissões
- Lógica de cobrança, pagamento ou cálculo financeiro
- Mudanças em infraestrutura, CI/CD ou configuração de deploy
- Migrations de banco de dados em produção
- Código que processa dados de saúde (HIPAA, LGPD)
- Qualquer mudança em código que já causou incidente antes
- Integrações com sistemas externos (APIs de pagamento, governo, seguradoras)
Pra se aprofundar em como sistemas realmente críticos são testados — não só revisados, mas testados com cobertura MC/DC e certificação formal — tem um artigo específico sobre testing em aviação, medicina e finanças que complementa o que cobri aqui. E pra ver o que acontece quando o review falha, os 10 bugs que mudaram a história da tecnologia são o melhor lembrete de por que a gente faz review.