[ Google AdSense 728×90 ]

trabalho em equipe · código

Sobrevivendo
ao code review.

O review é sobre o código, não sobre você. Como dar e receber comentários sem drama — e o que fazer quando discordar.

Ver como sobreviver →

O review é sobre o código, não sobre você

Code review ativa a mesma defensiva de qualquer feedback — só que aqui fica escrito, com seu nome, num PR que o time inteiro pode ver. É fácil sentir que cada comentário é um veredito sobre sua competência.

Não é. Review existe pra pegar bug antes de produção, manter consistência e espalhar conhecimento do código pelo time. Quanto mais comentários um PR recebe, mais gente está prestando atenção nele.

Um PR sem nenhum comentário não é elogio. É sinal de que ninguém revisou de verdade.

Como comentar de um jeito que ajuda

Comentário vago gera dúvida sobre o peso dele: é bloqueante? é sugestão? é só uma opinião? Prefixos resolvem isso:

01
blocking:
"Isso precisa mudar antes do merge — [motivo técnico claro]." Sinaliza que não é negociável sem uma justificativa em contrário.
02
nit:
Detalhe pequeno, não bloqueia o merge — só uma sugestão de estilo ou nome. Deixa claro que o autor pode ignorar sem culpa.
03
pergunta:
Não é crítica, é dúvida genuína — "me ajuda a entender por que você fez assim?" Evita que uma pergunta pareça acusação disfarçada.
04
elogio:
Comente o que ficou bom, não só o que precisa mudar. Review vira conversa, não só uma lista de defeitos.
[ Google AdSense 728×90 ]

Como receber sem virar embate

Um PR com 15 comentários parece um ataque, mas na maioria das vezes é só isso mesmo — 15 comentários. Trate cada um individualmente, não como um veredito coletivo sobre o PR inteiro.

Leia todos os comentários antes de responder qualquer um. Um comentário isolado, sem o contexto do resto, costuma parecer pior do que é.

Marque como "resolved" só o que você realmente resolveu. Usar o botão pra esconder um comentário que você não concorda não resolve o desacordo — só o tira de vista, e ele volta na próxima revisão de qualquer forma.


Quando discordar tecnicamente

Nem todo comentário está certo. Discordância técnica é normal e saudável — o problema é como ela se resolve.

01
Proponha uma alternativa com justificativa
Não "não concordo" — "prefiro X por causa de Y, faz sentido pra você?" Vira discussão técnica, não disputa de ego.
02
Dê um prazo pra decisão
Discussão técnica pode virar loop infinito de comentário. Combine um prazo — "decidimos até o fim do dia?" — pra fechar.
03
Chame uma terceira pessoa
Se depois de duas ou três trocas não chegou a um consenso, chame alguém neutro pra desempatar — em vez de deixar quem insiste mais alto ganhar.

O mesmo comentário técnico, dois jeitos de discordar:

❌ vai-e-vem infinito comentário no pr
colega Acho que deveria usar um Strategy pattern aqui em vez de if/else.
você Não acho necessário, if/else já resolve.
colega Mas fica difícil de estender depois.
você Também dá pra estender com if/else, não vejo motivo pra complicar.
[ 12 comentários depois ] PR travado há 3 dias. os dois continuam repetindo o mesmo ponto, sem critério pra fechar.
✓ alternativa com critério comentário no pr
colega Acho que deveria usar um Strategy pattern aqui em vez de if/else.
você Prefiro manter if/else por enquanto — são só 3 casos e não vejo sinal de crescer. Se surgir um 4º caso, migro pra Strategy. Faz sentido, ou tem algo que não estou vendo?
colega Faz sentido, só queria evitar que virasse um if/else gigante depois. Combinado.
[ resultado ] decisão fechada numa troca, com critério claro pra revisitar — sem precisar de terceira pessoa.

IA no code review: ajuda, mas não decide por você

Ferramentas de IA já pegam boa parte do óbvio antes de um humano abrir o PR — typo, estilo, bug simples. Use isso a seu favor: rode a triagem de IA antes de pedir revisão humana, e chegue com um PR mais limpo.

"Aprovado pela IA" não é aprovação. A responsabilidade final de decidir se algo vai pra produção é sempre de uma pessoa — IA erra, e às vezes erra de um jeito que parece muito confiante.

O mesmo vale pro lado humano: LGTM sem dizer o que você validou não ajuda ninguém a confiar no seu review. Se não tem nada a acrescentar, pelo menos diga o que você conferiu — "testei local, rodei os testes, aprovado" vale muito mais do que duas letras.

Sobreviver ao code review não é sobre nunca receber comentário — é sobre separar o peso de cada um, dar o mesmo cuidado que você espera receber, e lembrar que tanto humano quanto IA podem errar. Quem decide, no fim, é sempre uma pessoa.

Tem mais sobre comunicação e processo no trabalho em semrodeios.dev.br

Ver mais →