Hoje, no fim do dia, revendo uns pull requests, a coisa voltou. Não é a primeira vez. Olhei para o código de um colega, uma solução que funciona, mas é meio… torta. Aquele tipo de lógica que, tecnicamente, vai fazer o deploy funcionar, mas vai ser um inferno de manter daqui a seis meses, quando ninguém mais lembrar exatamente como aquele pedaço funciona. Fiquei ali, olhando para o bloco, e o incômodo não era com o código em si, era com a caixa de comentário. O que escrever?
É sempre assim. Sinto a pressão de ser analítico, de ver a falha potencial, mas ao mesmo tempo, sei como é receber um review que parece um interrogatório, não uma colaboração. Já estive do outro lado, claro. Aquele silêncio na daily depois de um feedback seco no seu PR, que faz parecer que você fez tudo errado. Não é desinteresse da minha parte, juro. É que a gente se afasta. A gente se protege.
Esse tipo de afastamento costuma nascer de uma comunicação mal calibrada. Treinar escuta ativa — inclusive leitura ativa — muda completamente o tom do review. Eu aprofundo isso em Escuta Ativa: A Técnica Simples Para Ser O Mais Inteligente Da Sala.
O Peso Silencioso da Ambiguidade
Lembro de uma vez que recebi um review curto: “Refatore. Complexidade desnecessária aqui.” Só isso. Sem exemplo, sem sugestão de caminho, nada. Passei a manhã tentando adivinhar o que era “complexidade desnecessária” na cabeça dele. O código em questão tinha acabado de resolver um bug crítico, o mais rápido que consegui, e sim, ficou meio feio, mas a pressa era real. Na minha cabeça, eu estava salvando o dia; na dele, eu estava criando débito técnico.
A diferença de perspectiva é brutal. E é isso que a gente tem que navegar no code review, especialmente ao dar um feedback construtivo. Não é sobre o código que está lá, é sobre a pessoa que escreveu ele, e a história por trás. É chato. É cansativo pensar nisso toda vez, no fim do dia, mas se a gente não pensa, a comunicação estraga tudo.
Eu começo a escrever. Apago. Escrevo de novo. Se eu digo “Sugiro usar o padrão aqui”, parece que estou dando uma aula, assumindo que ele não conhece o padrão . Se digo “Isso pode quebrar se acontecer”, parece que estou caçando erro e desconfiando do teste dele. A gente quer que o backlog ande, que a qualidade suba, mas o custo emocional de um feedback mal colocado é subestimado.
O Risco do “Está Funcional, Mas…”
O mais traiçoeiro é o review que não é sobre um bug. Se é um bug, é fácil. É objetivo. “A variável está nula na linha 157”. Fim. A gente conserta, agradece e segue. O problema é quando o código está funcional, mas ruim. É o caso agora.
A pessoa resolveu o problema, mas usou um loop aninhado onde um hashmap seria infinitamente mais limpo e rápido, especialmente com o volume de dados que o sistema lida. Ele não quebra hoje, mas vai explodir em produção daqui a três meses, numa sexta-feira à noite. Como dizer isso sem soar como “você fez errado”?
Eu tento focar na consequência, não na escolha. Em vez de focar no loop, foco no tempo de execução ou na manutenção futura.
“Entendi a lógica aqui para resolver o caso . Pensei no futuro: com o crescimento da base de dados, essa iteração pode se tornar um gargalo de performance no pior horário. O que você acha de explorarmos uma abordagem com lookup direto (talvez um map) para reduzir a complexidade temporal de para ? Seria uma refatoração pequena agora, mas nos poupa uma falha silenciosa mais adiante.”
É mais longo. Demora mais para escrever. Exige que eu calcule a complexidade, que eu pense no risco de deploy. Mas pelo menos transfiro o foco do “seu código é ineficiente” para “estamos evitando um problema futuro juntos”.
Ainda assim, a sensação de que estou sendo prolixo demais me ataca. Sou introvertido. Queria que o código falasse por si, que as convenções fossem claras o suficiente para não precisarmos desse malabarismo todo. Mas elas não são. E a minha parte no processo não é só analisar o código, é analisar o risco de relacionamento que vem com o feedback.
O Espelho Quebrado
Quando eu vejo uma gambiarra lógica, ou um atalho, eu não vejo só o colega. Eu vejo uma versão anterior de mim mesmo. Vejo o código que escrevi sob pressão, que prometi refatorar “assim que der”, e que está lá, firme e forte, esperando para me assombrar. A diferença é que agora eu tenho a chance de intervir no dele, e a forma como faço isso é a chave.
Não se trata de criar um sistema de review perfeito. Não acredito nessas coisas. É sobre reconhecer que a linha de código é só um sintoma. O code review é um lugar onde a pressa, a incerteza e o cansaço do dia a dia se encontram. E a gente tem que ser técnico o suficiente para ser preciso, mas humano o suficiente para lembrar que a pessoa que vai ler a minha observação está provavelmente tão esgotada quanto eu, olhando para a tela no fim do dia.
O meu feedback no PR de agora ficou assim:
“A solução está funcionando, ótimo. Antes de aprovar: na parte de persistência, esse método de fetch dentro do loop me preocupou um pouco pensando no volume de dados na semana que vem. Se a gente trouxer essa consulta para fora, ou usar um padrão de batch se for o caso, acho que ganhamos mais estabilidade na feature X. É o que a gente tentou fazer no projeto Y da última vez, lembra?”
Eu usei uma referência interna, que só a gente conhece. Fui específico. E foquei no futuro da feature, não no presente do código. Fechei o PR.
Ainda assim, não sei se é o jeito certo. É o menos errado que encontrei até agora. Talvez essa preocupação com o tom na hora de apontar um problema no código seja a mesma que me trava quando alguém me critica na reunião. A gente se protege. Fica em silêncio. E o silêncio, muitas vezes, é mal interpretado.
Existe um padrão de palavras que transformam um comentário técnico em ataque pessoal sem que a gente perceba. Eu listei essas armadilhas em Palavras que Matam Credibilidade Assíncrona.
É um esforço constante para manter o lado técnico e o humano separados, mas conectados. É como tentar manter um deploy totalmente automatizado, mas sabendo que a gente precisa estar de olho no log de erro. Sei lá. Talvez o problema não seja só o code review. Esse incômodo de não saber como reagir a um feedback inesperado ou a uma crítica sutil parece reaparecer em qualquer situação onde a gente se expõe. Nas reuniões, por exemplo, o silêncio é a primeira coisa que me ocorre.
Continue aprofundando
Se feedback técnico é um ponto delicado para você, estes textos ampliam essa reflexão:
• Dúvidas Técnicas: Clareza na Ajuda
• A Arte de Pensar Antes de Falar
• Como Vencer o Medo de se Tornar Referência Técnica
