Como revisar código ao vivo

O problema

Revisar código alheio ao vivo é um formato que derruba muita gente por um motivo simples:

parece que o objetivo é provar superioridade.

Quando a pessoa entra nessa, ela começa a:

• apontar detalhe demais
• usar tom absoluto
• criticar sem entender intenção
• confundir preferência com erro

Isso reduz o sinal da entrevista.

Modelo mental

Revisão boa não é desfile de opinião.

É leitura de risco com comunicação útil.

O avaliador quer ver se você consegue olhar para um trecho e responder:

• o que esse código está tentando fazer?
• onde está o maior risco?
• o que eu comentaria primeiro?
• como eu diria isso sem criar atrito desnecessário?

Se quiser resumir:

Em revisão ao vivo, julgamento técnico sem tato de colaboração costuma parecer imaturidade.

Quebrando o problema

Entenda a intenção antes de opinar

Antes de falar que algo está ruim, vale entender:

• qual problema o código resolve
• qual caminho escolheu
• qual hipótese parece estar por trás

Às vezes o problema não é a técnica em si.

É o encaixe dela no contexto.

Separe categoria de comentário

Nem todo comentário tem o mesmo peso.

Uma separação simples ajuda:

• bug ou comportamento incorreto
• risco de manutenção
• risco de performance
• clareza e legibilidade
• preferência de estilo

Isso melhora muito sua priorização.

Comente com impacto

Em vez de dizer “isso está ruim”, diga algo mais útil:

• o que te preocupa
• por que isso importa
• o que você faria em vez disso

Esse formato mostra raciocínio.

Evite absolutismo desnecessário

Frases muito rígidas costumam soar mal.

Melhor algo como:

• “aqui eu ficaria preocupado com…”
• “esse caminho pode gerar…”
• “eu consideraria…”

Não é fraqueza.

É precisão.

Exemplo simples

Imagine um código que faz consulta ao banco dentro de um loop.

Comentário ruim:

• “isso está horrível”

Comentário melhor:

• “aqui eu ficaria preocupado com N+1, porque cada item do loop dispara nova consulta. Se a lista crescer, esse trecho pode degradar bastante. Eu tentaria trazer esses dados de uma vez ou reorganizar a leitura.”

O segundo comentário mostra:

• que você identificou o problema
• que entendeu impacto
• que consegue sugerir direção

Erros comuns

• Corrigir estilo antes de olhar comportamento.
• Querer comentar tudo em vez de priorizar.
• Assumir contexto que o código não mostrou.
• Usar tom professoral.
• Criticar sem sugerir alternativa viável.

Como um senior pensa

Quem tem mais maturidade tende a fazer revisão como triagem de risco.

A cabeça fica parecida com:

• onde está o maior potencial de dano?
• o que mais afeta corretude, custo ou manutenção?
• o que é importante agora e o que pode virar follow-up?
• como comentar de um jeito que outra pessoa realmente consiga usar?

Essa postura produz menos ruído e mais valor.

O que o entrevistador quer ver

Ele quer ver se você:

• entende o objetivo antes de criticar
• prioriza riscos relevantes
• distingue fato técnico de preferência
• comenta com contexto e proposta
• consegue soar colaborativo sem perder firmeza

Revisão ao vivo boa não parece sermão.

Parece leitura técnica organizada.

Comentário forte não performa severidade. Ele reduz incerteza sobre risco e direção.

Em revisão ao vivo, clareza e priorização contam mais do que volume de apontamentos.