Code review que machuca e code review que ensina — a diferença
Recebi code reviews que me fizeram questionar se eu era bom o suficiente. E recebi code reviews que me tornaram um engenheiro melhor. A diferença estava em como o feedback era dado, não no feedback em si.
O primeiro code review que recebi de verdade deixou um comentário que não esqueci.
O comentário não era cruel. Era técnico, provavelmente correto. Mas foi escrito de um jeito que me fez sentir que eu tinha feito algo fundamentalmente errado, não que eu tinha escolhido uma solução que podia ser melhor.
Fiquei defensivo. Em vez de considerar o feedback com abertura, fiquei tentando justificar a escolha original. O resultado foi uma conversa que gerou calor sem gerar luz.
Code review é uma das ferramentas mais poderosas que um time tem para compartilhar conhecimento e melhorar qualidade de código. E é uma das ferramentas que mais frequentemente gera atrito desnecessário quando feita sem cuidado.
A distinção que aprendi a fazer é entre feedback sobre código e feedback sobre pessoa.
"Essa implementação vai ter problemas de performance quando o número de registros crescer — considera usar paginação aqui" é feedback sobre código. Diz o problema, diz por quê importa, sugere uma direção.
"Você não pensou em performance?" é feedback sobre pessoa. Infere uma falha de pensamento, não de implementação. Gera defensividade, não aprendizado.
A segunda formulação pode ser mais rápida de escrever. Mas o custo na relação de trabalho e no aprendizado do time é alto.
Aprendi a fazer code review a partir de uma lista de perguntas que me faço antes de comentar.
Esse problema que estou vendo é real ou é só diferente do que eu teria feito? Existem duas categorias de comentários em code review: problemas reais (bugs, problemas de segurança, performance, manutenibilidade) e preferências pessoais (formatação, nomes de variáveis, estrutura que é diferente mas igualmente válida). Os primeiros devem ser levantados. Os segundos, se o time não tem convenção estabelecida, são opcionais — e devem ser sinalizados como tal.
O comentário está descrevendo o problema ou atacando a solução? Existe a tendência de ir direto para "isso está errado, faz assim" sem explicar por que o original é problemático. Quando você explica o problema antes de sugerir a solução, a pessoa entende o princípio, não só a correção — e aplica esse entendimento em casos futuros que não são idênticos.
Estou dando contexto ou só emitindo um veredicto? "Não" sozinho não ensina nada. "Não, porque X, e o problema com X é Y, então considera Z" ensina.
Do lado de quem recebe code review, existe uma habilidade que demorei para desenvolver: separar o comentário da emoção que ele evoca.
Meu primeiro instinto quando recebia um comentário crítico era defensividade. O instinto é compreensível — você passou tempo naquele código, tomou decisões que pareciam certas. Mas defensividade fecha a possibilidade de aprendizado.
A pergunta que aprendi a fazer a mim mesmo antes de responder um comentário: "o revisor tem um ponto válido que eu não tinha considerado?" Mesmo quando a formulação do comentário é ruim, frequentemente a substância é boa.
Nem todo comentário precisa ser aceito. Às vezes você tem contexto que o revisor não tem. Às vezes é uma questão de preferência sem resposta objetiva. Mas distinguir entre "não concordo com a implementação" e "não estou considerando seriamente o feedback" é importante.
Um tipo de comentário que aprendi a valorizar — e que raramente vejo no início de carreira — é o comentário que elogia.
Não elogio vazio ("bom trabalho!"). Elogio específico que ensina o que foi feito bem e por quê importa. "A separação que você fez aqui entre lógica de validação e lógica de negócio torna essa parte muito mais fácil de testar" diz ao desenvolvedor o que reproduzir, não só o que evitar.
Code review que só aponta problemas cria uma relação onde submeter código para revisão parece exposição ao julgamento. Code review que também reconhece o que está funcionando cria uma relação de aprendizado mútuo.
Essa semana: no próximo code review que você fizer, antes de enviar cada comentário, verifique se ele descreve o problema ou só aponta a solução. Se só aponta a solução, adicione uma frase explicando por que o problema importa.