Em inglês, "Change this" soa muito mais duro do que "Mude isso" em português. Veja como pedir alteração, discordar e responder crítica sem estragar a relação com o time.
Em português, "Mude isso para um map" é um comentário normal de revisão. Traduzido ao pé da letra — "Change this to a map." — vira uma ordem em inglês. É o desencontro que mais custa relação a quem entra num time internacional: o comentário está tecnicamente certo e mesmo assim cria atrito.
A norma em code review em inglês é o hedging: transformar a ordem em pergunta ou sugestão. Compare os dois lados abaixo.
A fórmula que resolve quase tudo
Pergunta + motivo. "Could we use a map here? It would eliminate the nested loop." A pergunta devolve a decisão ao autor; o motivo justifica o pedido. E marque sempre se o comentário é blocking (precisa mudar) ou non-blocking (sugestão).
Consulte estas definições antes de avançar para os exemplos.
Compare as duas versões abaixo e toque na recomendada para ouvir.
Pedir uma mudança
✗ Change this to a map.
A pergunta devolve a decisão ao autor e o motivo justifica o pedido. O imperativo sozinho soa como ordem de quem manda.
Apontar um bug
✗ This is wrong.
Descreva o cenário que quebra, não o julgamento. O autor consegue verificar em dez segundos e ninguém precisa defender nada.
Sugerir sem bloquear
✗ Rename this variable.
O prefixo "nit" avisa que é preferência e "non-blocking" libera o merge. Sem isso, o autor não sabe se pode seguir.
Perguntar sem acusar
✗ Why did you do it like this?
"Why did you" soa a cobrança. Perguntar pelo caminho ("what led you to") pede a razão sem sugerir que houve erro.
Discordar do revisor
✗ No, you are wrong.
Assumir que pode faltar contexto seu abre espaço para o outro recuar sem perder a face — e a oferta de teste encerra a discussão com algo concreto.
Elogiar
✗ Ok.
Elogio específico é norma em revisão de time internacional. Ele equilibra a crítica e custa uma linha.
LGTM — Está bom para mim
Looks good to me. Aprovação curta, informal. Em revisão delicada, escreva a aprovação por extenso.
nit — detalhe opcional
Abreviação de nitpick. Marca um comentário pequeno, geralmente de estilo, que o autor pode ignorar.
blocking — bloqueia o merge
Precisa mudar antes de integrar: bug, risco ou quebra de contrato.
non-blocking — não bloqueia
Sugestão. Dizer qual é qual poupa uma rodada inteira de revisão.
request changes — pedir alterações
O botão que trava o merge. Use quando há blocking de verdade — travar por estilo irrita.
out of scope — fora do escopo
Resposta legítima a um pedido que não pertence a esta alteração. Abra um ticket separado.
Hedging demais também erra: um comentário cheio de rodeio fica ilegível e o autor não descobre o que precisa fazer. Seja direto quando houver risco real — segurança, perda de dados, quebra de contrato público: "This leaks the API key into the logs — blocking." Ninguém vai achar isso rude; vão achar responsável.
A regra prática: suavize a opinião, nunca o fato. "Acho que este nome ficaria melhor" pede rodeio. "Isto vaza a chave" não pede.
Três parágrafos curtos resolvem: o que mudou, por que e como testar. A justificativa é o que os revisores mais sentem falta — o código já mostra o "o que". Se a alteração for grande, avise onde começar a ler: "Start with the migration, the rest follows from it."
Marque o que ainda está em andamento como draft, e diga se você quer revisão de arquitetura ou só de detalhe: "Looking for feedback on the approach, not the naming yet." Isso muda completamente o tipo de comentário que você recebe.
"I have doubt about this" — em inglês, doubt é desconfiança, não dúvida. O certo é "I have a question about this". "Explain me this function" precisa da preposição: "explain this function to me". E a dupla negativa ("I didn't understand nothing") inverte o sentido em inglês padrão — use "I didn't understand anything".
Treine essas frases no módulo de inglês para programadores e veja também inglês no dia a dia do time.
respondidas 0/5
Escolha uma resposta e veja na hora se acertou. É para aprender — sem pressão.
1. Por que "Change this to a map." soa grosseiro em inglês?
Por quê: A norma em revisão é o hedging: transformar a ordem em pergunta ou sugestão ("Could we…?", "I'd suggest…").
2. O que o prefixo "nit:" comunica num comentário?
Por quê: "Nit" vem de nitpick: estilo ou preferência. Avisa o autor de que ele pode ignorar sem travar o merge.
3. Colocar "please" no fim de "Fix this" resolve o tom?
Por quê: O que suaviza é mudar a estrutura da frase (pergunta ou sugestão), não acrescentar uma palavra ao fim da ordem.
4. Qual a diferença entre blocking e non-blocking?
Por quê: Marcar qual é qual economiza uma rodada inteira: o autor sabe o que precisa resolver e o que pode deixar para depois.
5. Você discorda de um comentário do revisor. Qual abordagem funciona melhor?
Por quê: Assumir que pode faltar contexto seu abre espaço para o outro recuar sem constrangimento — e mantém a discussão sobre o código.
Próximo passo
Inglês no dia a dia do time de tecnologiaContinue estudando
Uma entrevista internacional segue um roteiro previsível. Veja cada etapa, o que se espera da sua resposta e as frases que resolvem os momentos difíceis.
9 min 18+ anos com quiz
Estudar agoraA daily é a reunião que você faz todo dia — e a que mais trava quem está começando em inglês. Veja a estrutura de três partes e as frases que sempre servem.
7 min 18+ anos com quiz
Estudar agoraPróximo passo
Para quem trabalha com tecnologia e quer atuar no exterior: entrevistas, reuniões diárias, revisão de código e termos técnicos do dia a dia.
532 termos e frases