O propósito da code review não é o revisor encontrar bugs. Quem depende da code review para encontrar bugs vive num paraíso de tolos.
Foi o Mark Dominus (@mjd) que escreveu isto no Mathstodon, numa curta publicação de Agosto de 2025. E é daquelas afirmações que, depois de lidas, não se consegue ignorar. Ficam lá, a ecoar, a fazer-nos pensar em todas as vezes que pedimos uma segunda opinião sobre código com a esperança de que alguém apanhasse aquela race condition ou aquele null pointer que nos escapou.
Eu já fiz isso. Tu já fizeste isso. Toda a gente que trabalha com software já fez isso.
A tese do mjd é simples e devastadora: não é possível, de forma geral, encontrar bugs examinando código. O cérebro humano não é um interpretador. Não consegue simular todos os estados possíveis de um programa com meia dúzia de saltos condicionais e loops encadeados. Quem acha que a code review vai eliminar bugs está a delegar responsabilidade a um processo que nunca foi desenhado para isso.
O que a code review faz bem é outra coisa.
O verdadeiro propósito
O mjd descreve-o assim: o revisor olha para o código e tenta perceber o que ele faz e como faz. Se não conseguir, esse código vai ser difícil de manter no futuro. E deve ser corrigido agora, enquanto o autor original ainda está familiarizado com ele.
É uma ideia que vira a conversa do avesso. Em vez de “apanhar erros”, o foco passa a ser “conseguir perceber o código sem esforço”. E isto muda tudo — as prioridades, o que se celebra nas revisões, a forma como se dá feedback.
Quantas vezes vi pull requests onde o comentário mais comum é “falta um semicolon” ou “esta variável devia ser const”, enquanto ninguém diz “não percebo o que esta função faz”? Acontece mais do que devia. Focamo-nos no trivial, no formatável, no que as ferramentas já detetam por nós, e ignoramos o que realmente importa: a clareza.
Mas e então os bugs?
Não estou a dizer que a code review nunca apanha bugs. Apanha. Mas não é fiável. Não é sistemática. E confiar nela como primeira linha de defesa é um erro de estratégia.
Para bugs, existem testes. Testes unitários, testes de integração, testes de sistema, fuzzing, análise estática, type checkers. Ferramentas que correm o código, que simulam entradas, que verificam invariantes. Isso sim consegue encontrar bugs de forma minimamente confiável.
A code review devia estar noutro patamar. Devia responder a perguntas como: este código faz sentido? Está no sítio certo? A abstração é adequada? Alguém que nunca viu isto vai perceber o que está a acontecer daqui a seis meses?
O contexto português
Esta reflexão é particularmente relevante para quem trabalha em equipas pequenas, startups, ou projetos open-source — que é o caso de muitos leitores daqui, e o meu também. Nestes contextos, a code review é muitas vezes uma formalidade. O reviewer está cansado, tem pouco contexto, e aprova. Ou então é o fundador da empresa que revisa tudo e diz sempre “LGTM” sem olhar a fundo.
Se calhar o problema não é a falta de tempo. O problema é estarmos a olhar para as coisas erradas. Se em vez de procurar bugs, pedíssemos ao revisor que lesse o código e nos dissesse o que não percebeu, a qualidade das revisões subia imediatamente.
É uma mudança subtil de objetivo que tem implicações gigantes.
O que levo disto
O post do mjd não inventa nada de novo — Donald Knuth já dizia que programar é contar ao computador o que queremos que ele faça, e comunicar com outros programadores o que queremos que o computador faça. Mas é um daqueles lembretes necessários.
Num mundo onde cada pull request é uma batalha de CI, onde os linters gritam mais alto que as pessoas, e onde o “ship fast” é quase um mandamento moral, vale a pena parar e perguntar: estamos a rever código pela razão certa?
Da próxima vez que abrires uma pull request, experimenta pedir ao revisor: “lê o código e diz-me o que não percebeste. Não procures bugs — isso são os testes que tratam.”
Pode ser que descubras que o teu código não é tão claro como pensavas. É aí que a code review realmente faz diferença.
Comentários (0)
Nenhum comentário ainda. Seja o primeiro!
Deixar comentário