Você já teve aquele colega que faz revisão de código como se estivesse num tribunal, pronto para condenar seu pull request (PR) à prisão perpétua sem direito a recurso?

 

Você escreve um código sólido, que refinou e testou, empurra o PR esperando um feedback técnico relevante e recebe comentários desaprovadores como:

  • “Esse if podia estar em uma única linha. Ficaria mais elegante”.

  • “A ordem dos imports deveria ser diferente, mesmo que funcione igual”.

  • “Não sei, mas essa indentação não me parece ideal”.

E aí o time inteiro, sem regras claras, acaba adotando a abordagem: “Faz só qualquer coisa e espera pra ver se ele aprova ou inventa mais um detalhe aleatório para julgar”.

 

Mas e se a revisão de código não fosse apenas sobre código?

É sobre pessoas, sobre ajudarmo-nos uns aos outros a crescer como developers, melhorar a qualidade do código juntos e, acima de tudo, evitar aquele clima de que alguém está certo e o outro errado.


Revisão de código bem feita não é aquela que só aponta o que está errado, mas sim aquela que explica o porquê e sugere como melhorar.

 

Por que fazemos revisão de código?

Revisar código é uma das práticas mais valiosas para qualquer equipe de desenvolvimento – aqui vai o porquê:

  • Melhora a qualidade do software
    Dois pares de olhos enxergam mais do que um. Revisar permite detetar bugs, falhas de lógica, violações de padrão e oportunidades de melhoria antes que o código chegue à produção.

  • Dissemina conhecimento
    Ao revisar, os developers aprendem sobre partes do sistema que talvez nunca tocariam de outra forma. Isso reduz pontos de falha e distribui melhor o entendimento técnico do projeto.

  • Desenvolve pessoas
    Quem revisa ensina e quem tem seu código revisado aprende. E isso vale tanto para quem está começando quanto para quem é experiente, mas acabou de chegar na equipe.

  • Evita código desnecessário
    Revisões impedem que funcionalidades duplicadas sejam criadas – algo muito comum quando o conhecimento está compartimentado ou mal documentado.

  • Fortalece o espírito de equipe
    Quando a revisão é feita com empatia, vira ponto de encontro entre experiência, criatividade e aprendizado. E todo mundo sai ganhando.

 

Como fazer revisões de código que ajudam ao invés de desmotivar

  • Explique o motivo do seu feedback
    Dizer “isso está errado” não ajuda. É muito mais útil e respeitoso dizer: “Esse método pode gerar um problema de performance porque X. Que tal essa alternativa?”.

  • Faça do PR uma conversa, não uma sentença
    Por vezes, o developer pode ter um bom motivo para ter feito daquela forma. Em vez de rejeitar seco, questione e debata. Pode acabar aprendendo algo também.

  • Lembre-se: o objetivo é aprender, não provar um ponto
    Se alguém mais júnior comete um erro, esse é o momento perfeito para ensinar e compartilhar. Corrigir com empatia ajuda muito mais do que só marcar o “X” vermelho.

  • Não se limite a criticar – elogie também
    Se viu um código limpo, uma solução inteligente ou um refator bem feito, diga. Reconhecimento faz parte do aprendizado e feedback positivo também é feedback.

  • O código é da equipe, não de um único developer
    O objetivo final é um sistema bem feito. Não importa quem ganhou o argumento, mas sim que o time entregue algo com qualidade, clareza e performance.

 

Mas e o famoso Looks Good To Me (LGTM)?

Existe também o outro lado da moeda: revisões de código rápidas e superficiais demais. Se você passou duas semanas escrevendo um PR e a revisão volta em 30 segundos com um LGTM, tem algo errado.

Uma aprovação rápida demais pode indicar que:

  • O revisor nem leu o código e só quer se livrar da tarefa.

  • A equipe não tem um padrão de qualidade bem definido.

  • O código pode conter bugs ou decisões questionáveis que ninguém notou.

 

Então, tão ruim quanto rejeitar sem explicação é aprovar sem revisão real.

 

O ideal? Encontrar um equilíbrio entre feedback construtivo e produtivo, sem ser um obstáculo ao fluxo de trabalho.

 

Exemplos da vida real: salvando commits (e sprints)

1) Módulo duplicado salvo a tempo

Teve uma vez em que um developer criou um módulo inteiro para lidar com um tipo de erro específico na geração de relatórios. Tudo bem feito, testado, caprichado. Mas… já existia um ErrorHandler que fazia exatamente isso – só que com outro nome e num namespace menos óbvio.

 

A revisão evitou um commit desnecessário, reduziu complexidade e ainda serviu para explicar ao novo colega: “Aqui já temos um padrão para isso. Quando for lidar com erro de integração, dê uma olhada nesse handler primeiro.”

 

Resultado? Código limpo, sprint entregue no prazo e uma pessoa nova no time que agora conhece melhor o sistema.

 

2) Adapters e a falta de comunicação

Em outra ocasião, durante um upgrade de framework, várias dependências precisavam ser mantidas por conta da idade do código. Sem clareza de quem fazia o quê, alguns developers (eu incluso) criaram adaptadores para facilitar o uso de dados repetidos entre dependências inter-relacionadas.

 

Por falta de comunicação e urgência do prazo, esses adapters ficaram – mesmo havendo versões mais atualizadas e limpas. Ninguém falou nada nos pull requests. Resultado? Código desnecessário, nenhuma melhoria real e a equipe perdeu a chance de crescer tecnicamente.

 

3) Cache, integridade e contexto

Em um sistema de alta disponibilidade, precisei cuidar de um processo de buffer de logs em cache de memória que depois fazia dump no banco. Era crítico para performance.

 

Implementei um hash para garantir integridade dos dados. Na revisão, o Tech Lead apontou um problema importante: o sistema do cliente não aguentaria objetos tão grandes na memória. O tipo de insight que só alguém com tempo de casa e contexto do ambiente poderia ter.

 

Essa troca não só melhorou o sistema como me deu um entendimento muito mais profundo das restrições não óbvias do cliente.

 

Perguntas que valem ouro durante a revisão

Eis algumas questões orientadoras que podem ajudar neste processo:

  • Estas alterações vão melhorar a qualidade agora e no futuro?

  • O código está bem desenhado e fácil de manter?

  • Está testado e faz tudo o que se propõe a fazer?

  • Pode introduzir bugs, brechas de segurança ou performance?

  • Está alinhado com os padrões e decisões já adotadas pela equipe?

 

Conclusão

Se a revisão de código fosse um jogo, não seria “quem erra mais” ou “quem caça mais bugs”, mas sim um “co-op” de alta performance, onde cada pull request vira uma chance de:

  • Colaborar em vez de competir;

  • Aprender em vez de apenas apontar erros;

  • Compartilhar contexto em vez de isolar conhecimento;

  • Entregar código sólido sem perder a alegria (e o bom humor!).

No fim das contas, o melhor feedback é aquele que nos faz reconhecer que o produto final melhorou mesmo e que aprendemos algo novo.

 

Então, da próxima vez que você for revisar um PR, lembre-se: você não está de terno no tribunal, mas sim de boné na blitz de código. Respire fundo, traga empatia, e bora jogar esse game de equipe até à vitória de todos!

 

Quer aprender mais sobre revisões de código com um toque humano?

Recomendo a leitura de:
Partilha este artigo