code review como dev junior: como receber comentário sem travar

O primeiro code review como dev junior dá um frio específico. Você abre o pull request, vê sete comentários, dois pedidos de mudança, uma pergunta que parece óbvia para quem fez e uma sugestão de refatoração que você nem sabia que existia. A cabeça traduz rápido: “meu código é ruim”, “o time achou que eu não sei nada”, “vou ser demitido”.

Calma.

Code review não é boletim escolar. Não é humilhação pública. Não é uma prova para descobrir se você merece estar ali. Code review é uma ferramenta para melhorar mudança antes dela virar parte do produto. Comentário em PR não significa fracasso; significa que o time está usando o processo.

Para dev junior, aprender a receber review é tão importante quanto aprender sintaxe. O time confia mais em quem responde bem, pergunta com contexto, ajusta sem drama e entende padrões do projeto do que em quem tenta parecer genial no primeiro commit.

Se você ainda está antes desse ponto, leia primeiro o guia de primeiro pull request como dev junior. Este texto começa quando o PR já está aberto e alguém começou a revisar.

leia tudo antes de responder

O impulso inicial é responder comentário por comentário no susto. Você lê a primeira crítica, sente que precisa se defender, escreve uma resposta longa e só depois percebe que o terceiro comentário explicava o problema inteiro.

Não faça review no modo reação.

Quando os comentários chegarem, faça assim:

1. leia todos sem responder;
2. separe o que é pedido de mudança, pergunta, sugestão ou dúvida;
3. identifique comentários repetidos sobre o mesmo padrão;
4. só então responda e ajuste.

Esse intervalo de leitura muda o tom. Você sai de “preciso provar que pensei nisso” para “preciso entender o que o revisor quer proteger”.

Um comentário como “por que isso fica no componente?” pode não ser acusação. Pode ser uma pergunta real sobre arquitetura. Um “prefiro extrair essa regra” pode não significar que seu código está horrível. Pode significar que o time já tem um padrão para esse tipo de validação.

não responda como se estivesse no tribunal

Junior costuma transformar cada comentário em defesa:

Eu fiz assim porque achei que era melhor, mas posso mudar se quiser.

Essa resposta parece humilde, mas carrega tensão. Ela coloca o revisor na posição de juiz e você na posição de réu.

Prefira respostas objetivas:

Faz sentido. Vou mover essa regra para o helper usado nos outros formulários.

Ou, quando não entendeu:

Entendi a preocupação com duplicação. Você prefere que eu reaproveite `validatePhone` ou crie uma função específica para esse caso?

Ou, quando tem contexto que talvez o revisor não viu:

Eu mantive aqui porque esse fluxo aceita telefone opcional, diferente do cadastro principal. Mesmo assim, dá para extrair a parte comum. Vou ajustar desse jeito.

Perceba a diferença: você não está brigando para vencer. Está colaborando para chegar em uma mudança melhor.

aceite comentário pequeno sem transformar em debate

Nem todo comentário precisa virar discussão técnica profunda. Se alguém pede para renomear variável, ajustar texto, quebrar linha, usar padrão de import ou seguir convenção do time, provavelmente é mais barato ajustar do que escrever três parágrafos.

Isso não significa obedecer cegamente. Significa escolher onde gastar energia.

Uma boa regra:

Se a mudança é pequena, segura e segue padrão do projeto, ajuste. Se muda comportamento, arquitetura, prazo ou escopo, pergunte.

Exemplos de ajuste direto:

• trocar data por userProfile;
• usar helper já existente;
• mover teste para pasta padrão;
• corrigir mensagem de erro;
• remover console/log esquecido;
• atualizar descrição do PR.

Exemplos que merecem pergunta:

• reescrever a solução inteira;
• mudar contrato de API;
• mexer em regra de negócio não combinada;
• alterar comportamento de produção;
• aumentar muito o escopo do PR.

Responder bem não é dizer sim para tudo. É saber diferenciar comentário operacional de decisão de produto/arquitetura.

quando discordar, traga evidência

Discordar em review é normal. O problema é discordar com sensação, ego ou “na minha máquina funcionou”.

Resposta ruim:

Acho melhor deixar assim porque fica mais simples.

Resposta melhor:

Minha preocupação em extrair agora é que os outros dois fluxos têm validações diferentes e a função ficaria cheia de `if`. Posso manter local neste PR e abrir um ticket para consolidar as validações depois?

Outra resposta boa:

Testei os três casos que quebravam antes: telefone vazio, DDD sem número e número completo. Com a sugestão de mover para o helper, o caso de telefone opcional passa a falhar. Posso adaptar o helper para receber `required: false`, mas isso aumenta o escopo. Qual caminho você prefere?

Você não está dizendo “não” por orgulho. Está mostrando consequência. Isso é maturidade.

faça commits de ajuste fáceis de revisar

Depois dos comentários, evite um commit gigante chamado fix review. Ele dificulta a segunda rodada porque ninguém sabe o que mudou.

Se o time usa squash no final, ainda assim commits intermediários claros ajudam:

fix: reuse phone validation helper
fix: add optional phone test case
chore: update PR description with test evidence

Se o time prefere um commit único, tudo bem. Mas durante o review, organize seus ajustes mentalmente e explique no comentário:

Ajustei em três pontos:
- movi a validação para `validatePhone`
- adicionei teste para telefone opcional
- atualizei a mensagem de erro para seguir o padrão do cadastro

Isso economiza tempo do revisor. E economizar tempo do revisor é uma das formas mais rápidas de ganhar confiança como junior.

responda depois de corrigir, não antes

Um erro comum é responder “vou ajustar” em dez comentários e sumir. Melhor é ajustar primeiro e depois responder com o que foi feito.

Exemplo:

Ajustado no commit `abc123`: movi para `validatePhone` e cobri o caso de DDD ausente no teste `phone-validation.test.ts`.

Se o ajuste vai demorar, aí sim avise:

Vou ajustar essa parte junto com os comentários sobre validação. Devo subir nova versão ainda hoje.

O ponto é fechar loop. Review bom tem rastreabilidade: comentário recebido, mudança feita, evidência dada.

peça contexto quando o comentário vier seco

Nem todo sênior escreve review didático. Às vezes o comentário vem curto:

isso não deveria ficar aqui

Você pode sentir vontade de responder seco também. Não ajuda.

Transforme em pergunta concreta:

Você prefere que essa regra vá para o service ou para o helper de validação? Vi os dois padrões no código e não consegui identificar qual é o recomendado para esse fluxo.

Essa resposta faz duas coisas: mostra que você olhou o projeto e obriga a conversa a sair do julgamento genérico para uma decisão prática.

Outra opção:

Pode me apontar um arquivo que segue o padrão esperado? Eu replico o formato aqui.

Pedir exemplo não é fraqueza. É como junior aprende padrão real do time.

não use review para provar que você sofreu

Evite respostas como:

Passei a noite fazendo isso.

ou:

Mas foi assim que me explicaram.

ou:

Eu ainda sou junior, então não sabia.

Mesmo quando tudo isso é verdade, não resolve o PR. O review precisa melhorar a mudança, não negociar culpa.

Se a tarefa estava confusa, transforme em ação:

A descrição original não deixava claro esse caso. Vou ajustar o PR e também sugerir uma nota no ticket para deixar a regra explícita.

Se faltou contexto, transforme em aprendizado:

Não conhecia esse helper. Vou usar aqui e anotar no meu mapa do projeto para os próximos formulários.

Isso comunica maturidade sem autopunição.

depois do merge, capture o padrão

Quando o PR for aprovado, não feche a aba e finja que acabou. O valor do review está no padrão que você leva para o próximo PR.

Anote três coisas:

1. quais comentários apareceram mais de uma vez;
2. qual padrão do projeto você descobriu;
3. o que pode checar antes de abrir o próximo PR.

Exemplo:

Aprendizados do PR:
- validação de formulário fica em `src/validators`, não no componente
- teste deve cobrir campo vazio e formato inválido
- descrição do PR precisa listar evidência manual + teste automatizado

Isso vira checklist pessoal. Na próxima mudança parecida, você antecipa metade do review.

Se você está nos primeiros 30 dias como dev junior, esse hábito vale ouro. Ele mostra curva de aprendizado visível: o time comentou uma vez, você absorveu e reduziu o mesmo problema no PR seguinte.

checklist antes de pedir nova revisão

Antes de marcar o revisor de novo, confira:

• respondi todos os comentários ou deixei pergunta explícita?
• rodei os testes relevantes depois dos ajustes?
• atualizei descrição do PR se o escopo mudou?
• removi debug, comentário temporário e código morto?
• deixei commits ou mensagem claros o bastante para segunda revisão?
• expliquei o que mudou desde a primeira rodada?

Mensagem simples para pedir nova rodada:

Subi os ajustes da revisão.

Mudanças principais:
- extraí a validação para o helper existente
- adicionei teste para telefone opcional
- mantive o comportamento do cadastro principal sem alteração

Teste: `npm test phone-validation` passou localmente.

Isso é muito melhor que apenas “ajustado”.

o sinal que o time procura

No começo da carreira, você talvez ache que o time procura código perfeito. Não procura. Código perfeito de junior não existe, e nem de sênior.

O sinal real é outro: você recebe feedback sem desmoronar, entende padrão, faz ajuste pequeno, pergunta quando precisa, não esconde dúvida, não transforma review em guerra e melhora no PR seguinte.

Esse comportamento acumula confiança.

Um dev junior que responde bem a code review vira mais fácil de orientar. E gente fácil de orientar cresce mais rápido, recebe tarefas melhores e aprende mais com o mesmo time.

O objetivo não é sair do review sem comentário. O objetivo é sair do review melhor do que entrou.