Como aprendi a dar code review antes de saber receber review
Meu primeiro code review que dei foi antes de entender o que era review bom. O que aprendi sobre review dando, não recebendo — e por que a perspectiva muda tudo.
Aprendi mais sobre code review dando review do que recebendo.
Não porque eu fosse bom nisso. Pelo contrário — fui péssimo no começo. E perceber o que estava fazendo errado como revisor me ensinou mais sobre o que eu devia procurar no próprio código do que qualquer PR que recebi.
Meu primeiro review real
Na POA Software, a cultura era de revisão por pares. Não era opcional. Todo PR ia para pelo menos uma pessoa antes de merge.
Meu primeiro review de verdade foi de um PR de um colega mais experiente. Código limpo, bem estruturado, fazia sentido. Fiquei olhando por 20 minutos sem saber o que comentar.
Aprovei sem comentário.
Depois perguntei pro tech lead se estava certo. Ele disse: "Aprovação sem comentário não é review. É rubber stamp."
Expliquei que o código estava bom. Ele disse: "Como você sabe? O que você verificou?"
Não sabia responder. Tinha olhado o código, achei que entendia, aprovei. Mas não tinha verificado nada de forma sistemática.
Fui desenvolvendo uma checklist mental com o tempo: comportamento (o código faz o que o PR descreve? — quando possível, rode localmente), casos de borda (o que acontece com input vazio? com null? com concorrência?), legibilidade (se você precisar explicar este código para alguém em seis meses, consegue?), consistência (o código segue o padrão do projeto? inconsistência precisa de motivo explícito), e testes (se o PR adiciona funcionalidade, tem teste para o comportamento? se corrige bug, tem teste que garante que o bug não volta?).
O que não fazer em review — aprendi do jeito mais chato, percebendo que estava fazendo:
Não comenta estilo se tem linter. Se o projeto tem ESLint ou Black configurado, o linter cuida de formatação. Não reescreve o código do outro no comentário — "eu faria assim: [código completo]" não é review, é reescrita não solicitada. Não aprova por educação — "o código está OK, acho" quando você não está seguro é o oposto de útil; pergunta em vez de aprovar na dúvida. E não bloqueia por preferência — há diferença entre problema (bug, vulnerabilidade, comportamento inesperado) e preferência (você teria nomeado a variável diferente). Bloquear PR por preferência é usar review para impor estilo pessoal.
O que review te ensina sobre o próprio código
Quando você revisa código de outros ativamente, começa a notar padrões no próprio código.
Quando você tem dificuldade de entender o fluxo de um PR, você volta e olha o próprio código: "Alguém que fosse revisar meu último PR conseguiria seguir o fluxo?"
Quando você encontra um edge case não tratado num PR alheio, você pensa: "Será que o meu último endpoint tem o mesmo problema?"
Review não é sobre apontar problemas dos outros. É sobre calibrar o padrão do que você mesmo aceita como pronto.
O comentário que mudou como eu dava review
Depois de alguns meses, o tech lead fez um comentário num review que dei:
"Esse comentário está correto, mas vai soar como crítica. Reformula para ser pergunta."
Tinha escrito: "Isso vai quebrar em concorrência."
Devia ter escrito: "O que acontece se dois requests chegarem simultâneos aqui? Teria como o mesmo ID ser processado duas vezes?"
A segunda versão diz a mesma coisa. Mas abre diálogo em vez de fechar. O autor pode responder "não, porque tem lock aqui" — e eu aprendo algo que não tinha visto. Ou pode responder "você está certo, corrigindo" — e o problema é resolvido sem conflito.
Review como diálogo, não como julgamento. Demorei um tempo para entender a diferença na prática.
Essa semana: pega o último PR que você aprovou. Você verificou casos de borda? Você rodou localmente ou rastreou o fluxo? Se não, o próximo PR você faz isso antes de aprovar — e vê se muda o que você comenta.