Code review é uma daquelas práticas que todo mundo concorda que é importante e quase ninguém foi ensinado a fazer bem. A gente aprende a escrever código, mas raramente aprende a comentar o código dos outros sem soar arrogante, mesquinho ou, no outro extremo, inútil de tão leniente.
E o problema é real: um review mal conduzido azeda o clima do time, faz gente ter medo de abrir pull request e transforma uma ferramenta de qualidade numa fonte de atrito. A boa notícia é que dar bom feedback técnico é uma habilidade — e, como toda habilidade, dá para aprender.
Separe o que é padrão do que é gosto
Metade dos conflitos em review nasce daqui. Existe uma diferença enorme entre “isso tem um bug que vai quebrar em produção” e “eu teria escrito de outro jeito”. A primeira é objetiva; a segunda é preferência pessoal disfarçada de padrão.
Antes de escrever um comentário, vale a pergunta honesta: isso está errado ou está apenas diferente do que eu faria? Se for diferente, e funciona, e é legível — deixa passar, ou no máximo sugere como opinião, deixando claro que é opinião. Guardar a sua energia de review para o que importa de verdade faz o seu “não” pesar quando ele realmente precisar pesar.
Um bom revisor briga pelos bugs e cede nos gostos. Quem briga por tudo perde a autoridade justamente quando ela importa.
Comente o código, não a pessoa
É uma diferença sutil de linguagem com um efeito enorme. “Você não tratou o caso de lista vazia” coloca o dedo na pessoa. “Esse trecho quebra se a lista vier vazia — falta tratar esse caso” aponta para o código. Mesma informação, temperatura completamente diferente.
Não é sobre encher de gentileza vazia. É sobre manter o foco no artefato, que é o que está em discussão. Ninguém fica na defensiva quando você fala do código; todo mundo fica quando parece um julgamento pessoal.
Explique o porquê, não só o quê
“Troca isso por um map” é uma ordem. “Um map aqui deixaria a intenção mais clara e evita o índice manual, que é onde costuma entrar bug” é ensino. A segunda versão dá mais trabalho para escrever, mas faz três coisas: convence pela razão, ensina algo que vale além daquela linha e respeita a autonomia de quem recebe — que pode, inclusive, discordar com um bom argumento.
Review sem o porquê vira imposição. Com o porquê, vira uma conversa técnica entre pessoas que querem o mesmo resultado. E, num time saudável, é isso que o review deveria ser.
Elogie o que está bom
Parece bobagem, mas muda o tom de tudo. Se os seus comentários são sempre e só apontando defeitos, o autor passa a associar o seu nome a dor. Um “boa, não tinha pensado em tratar esse caso” ou “essa função ficou bem limpa” custa dois segundos e faz o feedback difícil, quando vier, ser recebido de peito aberto em vez de na defensiva.
Não é puxar saco. É reconhecer o que realmente ficou bom — o que, de quebra, sinaliza para o time o padrão que você quer ver mais vezes.
Sinalize a gravidade
Nem todo comentário tem o mesmo peso, e quem lê não adivinha. Deixe explícito o que trava o merge e o que é só um toque. Um prefixo simples resolve boa parte da confusão:
- Bloqueante: precisa mudar antes de mergear (um bug, uma falha de segurança).
- Sugestão: eu faria diferente, mas fica a seu critério.
- Curiosidade: só quero entender por que você foi por esse caminho.
Isso evita o mal-entendido clássico em que o autor reescreve meio pull request por causa de um comentário que, no fundo, era só um “acho que”. E poupa o review de virar uma negociação exaustiva sobre o que era obrigatório e o que era palpite.
Automatize as discussões de gosto
A forma mais eficaz de tirar o atrito do review é fazer com que boa parte dele nem precise acontecer. Discussões sobre ponto e vírgula, aspas simples ou duplas, indentação, ordem de imports — nada disso deveria ocupar o cérebro de um ser humano num pull request. Coloque um formatador automático e um linter na esteira, combine as regras uma vez com o time, e deixe a máquina ser a chata.
Com o gosto padronizado no automático, sobra espaço para o review discutir o que realmente exige um par de olhos humano: a lógica está correta? Os casos-limite foram tratados? O nome dessa função conta a verdade? A abordagem é a mais simples que resolve? São essas perguntas que agregam — e são justamente as que se perdem quando metade dos comentários é sobre formatação.
Como bônus, ninguém leva para o pessoal uma bronca vinda de um linter. A máquina não tem tom.
No fim, é sobre o mesmo lado
O deslize de fundo é encarar o review como você contra o autor — quem acha mais erro, ganha. Não é. Vocês estão do mesmo lado, contra o bug, contra a complexidade desnecessária, contra o código que ninguém vai entender daqui a um ano. Quando o feedback parte daí, ele deixa de soar como ataque e vira o que sempre deveria ter sido: duas pessoas cuidando juntas de um código que é do time, não de uma delas.
