Revisão de código sem agir como se você fosse o ESLint

O problema

Tem revisão de código que ajuda.

E tem revisão de código que só desgasta.

Você já viu esse segundo tipo.

É a revisão que vira:

• guerra de estilo
• gosto pessoal travestido de padrão
• comentário em cima de cada linha irrelevante
• microcorreção que IDE, formatter ou linter já resolveriam

Enquanto isso, passam batidos problemas como:

• risco de comportamento errado
• acoplamento ruim
• nome confuso
• complexidade desnecessária
• fluxo difícil de manter

O resultado é péssimo.

Quem revisa acha que está sendo cuidadoso.

Quem recebe sente que está apanhando por detalhe sem importância.

E a qualidade real da mudança quase não melhora.

Modelo mental

Pense assim:

code review não existe para provar que você enxerga defeitos. Existe para aumentar a qualidade da mudança antes que ela entre no sistema.

Essa mudança de lente é importante.

Porque ela tira a revisão do campo da performance pessoal e leva para o campo da utilidade.

A pergunta deixa de ser:

• “o que eu consigo comentar?”

e passa a ser:

• “o que aqui realmente merece atenção humana?”

Isso já melhora muito a qualidade da revisão.

Quebrando o problema

Linter, formatter e teste já deveriam carregar a parte mecânica

Se a revisão humana está gastando energia demais com:

• indentação
• aspas
• ordem trivial
• convenção repetitiva

tem algo errado no processo.

Essas coisas, quando forem padrão do time, idealmente deveriam estar automatizadas.

Não porque elas nunca importam.

Mas porque atenção humana é cara.

E vale mais gastá-la em:

• entendimento
• risco
• clareza
• trade-off

do que em correção mecânica.

Nem todo comentário tem o mesmo peso

Esse ponto é central.

Comentário sem prioridade vira ruído.

Na prática, review melhor costuma separar algo como:

• bloqueio real
• preocupação importante
• sugestão opcional
• nit cosmético

Sem essa distinção, tudo parece urgente.

E quando tudo parece urgente, nada fica legível.

Comentário bom fala de consequência

Muita revisão ruim soa assim:

• “eu faria diferente”
• “acho melhor mudar isso”
• “não gostei desse nome”

Isso é fraco.

Porque não explica o impacto.

Comentário forte costuma ter estrutura mais útil:

• o que chamou atenção
• por que isso pode ser problema
• que risco ou custo ele cria
• qual direção faria mais sentido

Exemplo:

em vez de:

“Esse helper ficou estranho.”

algo como:

“Esse helper juntou dois fluxos que parecem similares, mas mudam por motivos diferentes. Meu receio é a gente esconder regras distintas atrás da mesma abstração e dificultar manutenção depois.”

A diferença é grande.

Revisão boa protege legibilidade futura

Nem todo problema aparece como bug.

Às vezes o dano é:

• leitura lenta
• comportamento difícil de prever
• mudança futura cara
• onboarding mais confuso

Isso também entra em review.

Mas precisa ser explicado com critério, não com frase vaga do tipo:

“isso não ficou clean”

“Clean” sozinho não quer dizer nada.

Legibilidade com contexto, sim.

Review não é palco para demonstrar superioridade

Isso merece ser dito diretamente.

Tem revisão que vira performance de ego.

O revisor faz comentário demais para mostrar repertório, rigidez ou sofisticação.

Só que o objetivo não é parecer a pessoa mais criteriosa da thread.

É melhorar a mudança.

Às vezes o review mais maduro é curto e certeiro.

Poucos comentários, mas nos pontos que realmente importam.

Bloquear é uma decisão cara

Tem gente que bloqueia PR cedo demais.

Quase como reflexo.

Mas bloquear significa:

• atrasar entrega
• puxar mais rodada de contexto
• aumentar custo emocional da revisão

Então bloquear vale quando o problema é relevante de verdade, por exemplo:

• bug provável
• risco operacional
• comportamento ambíguo demais
• design que prende o time em custo alto logo depois

Se for preferência leve, talvez a resposta melhor seja sugestão, não bloqueio.

O melhor review considera estágio e contexto

Isso pesa muito.

A mesma mudança pode merecer rigor diferente dependendo de:

• criticidade do fluxo
• prazo real
• maturidade do módulo
• reversibilidade
• tamanho do risco

Um review maduro não usa a mesma régua para tudo.

Ele ajusta profundidade sem abandonar critério.

Exemplo simples

Imagine um PR que extrai uma função genérica para reaproveitar lógica entre dois fluxos.

Resposta fraca:

“Prefiro não abstrair. Está overengineered.”

Pode até estar certo, mas ainda está pobre.

Resposta melhor:

“Meu receio aqui não é a abstração em si, e sim o momento dela. Os dois fluxos ainda têm diferenças importantes de regra e de evolução. Se juntarmos agora, pode ficar mais difícil mudar um sem afetar o outro. Eu tenderia a manter explícito por enquanto e revisitar abstração quando o padrão estiver mais estável.”

Essa resposta faz algumas coisas certas:

• identifica o ponto real
• explica consequência
• evita tom de autoridade vazia
• sugere direção prática

Erros comuns

• Tratar review como caça a detalhe cosmético.
• Comentar sem dizer impacto ou prioridade.
• Bloquear por gosto pessoal.
• Fazer comentário técnico para parecer sofisticado, não para ajudar.
• Ignorar contexto de risco, prazo e criticidade da mudança.

Como um senior pensa

Quem amadureceu costuma pensar assim:

“Se eu tiver pouca atenção para gastar neste review, onde ela gera mais redução de risco e mais aumento de clareza?”

Essa é uma ótima pergunta.

Porque obriga você a priorizar.

E revisão boa é isso também:

priorização.

Você não está lendo código para opinar sobre tudo.

Está lendo para melhorar o que mais importa antes do merge entrar.

O que o entrevistador quer ver

Quando esse tema aparece em entrevista, o avaliador normalmente está tentando entender se você:

• sabe diferenciar automação de julgamento humano
• consegue priorizar problemas de review
• dá feedback com clareza e respeito
• entende que revisão é parte da qualidade da entrega, não ritual social
• sabe balancear critério com pragmatismo

Resposta forte costuma mostrar:

1. o que você procura primeiro num PR
2. o que te faria bloquear
3. o que viraria sugestão
4. como você escreve feedback para aumentar chance de adoção

Se isso aparecer, a resposta já fica muito acima do padrão “eu reviso clean code e boas práticas”.

Review bom não tenta comentar tudo. Tenta acertar o que mais importa.

Quem age como ESLint demais geralmente deixa passar o que só julgamento humano conseguiria pegar.