Code Review:
Como Fazer Revisões Que Desenvolvem o Time

O que code review realmente é (e não é)

Code review começou como ferramenta de detecção de bugs. E continua sendo isso — mas em times que fazem code review bem, encontrar bugs é quase um efeito secundário. O valor principal está em outro lugar: compartilhamento de contexto, transferência de conhecimento e alinhamento de padrões técnicos.

Quando um desenvolvedor sênior revisa o código de um júnior e escreve comentários explicando por que uma determinada abordagem cria problemas de manutenção, ele está fazendo algo que nenhuma ferramenta automatizada faz: transmitindo julgamento técnico contextualizado. Isso acelera o crescimento do dev muito mais do que qualquer treinamento formal.

Por outro lado, code review não é: (a) uma ferramenta para o tech lead demonstrar superioridade técnica, (b) uma oportunidade para forçar preferências de estilo sem base técnica, (c) um portão que o tech lead precisa revisar sozinho, ou (d) um processo que deve bloquear entrega por mais de 24 horas para qualquer PR não crítico.

O custo do code review ruim

Code review mal conduzido tem custos que vão além da fricção técnica. Revisores que usam PR comments para demonstrar conhecimento técnico ou para criticar de forma desproporcional criam um ambiente onde as pessoas evitam submeter código inacabado para feedback — e perdem exatamente a fase onde feedback tem mais valor.

Devs que recebem revisões excessivamente críticas ou condescendentes aprendem a não tomar riscos técnicos. A solução pragmática — código conservador, no padrão estabelecido, sem experimentação — passa nas revisões mais facilmente. E o time perde a diversidade de abordagens e o aprendizado que vem de tentar coisas diferentes.

Há também o problema do gargalo: quando um único revisor (frequentemente o tech lead ou senior mais experiente) é o único aprovador de todos os PRs do time, a velocidade de entrega está limitada pela capacidade de revisão dessa pessoa. E quando essa pessoa está em reuniões, em férias ou simplesmente ocupada, o fluxo para.

"Um code review bem feito ensina mais do que qualquer documentação. Um code review mal feito destrói a disposição de aprender de qualquer forma."

Como dar feedback em code review sem desmotivar

A linguagem do code review importa muito mais do que a maioria dos revisores percebe. Há uma diferença enorme entre "isso está errado" e "aqui estou pensando em um problema potencial — o que você acha de X abordagem?" A primeira encerra a conversa. A segunda abre diálogo.

Práticas que funcionam:

• Faça perguntas: "Você considerou como isso se comportaria sob carga?" é muito mais educativo do que "Isso não vai escalar." A pergunta obriga o dev a raciocinar, não apenas a implementar a correção que o revisor prescreveu.
• Explique o porquê: "Prefiro usar X em vez de Y" sem explicação é preferência arbitrária. "Prefiro X aqui porque Y cria acoplamento implícito com Z que vai dificultar testes" é conhecimento transferível.
• Reconheça o que está bom: code review que só aponta problemas cria uma relação de ansiedade. Comentários positivos específicos ("essa abstração aqui ficou elegante") reforçam comportamentos que você quer ver mais.
• Seja claro sobre prioridade: sem hierarquia de comentários, o dev não sabe se um nit de nome de variável tem o mesmo peso que um bug crítico de segurança. Deixe explícito o que é bloqueante e o que é sugestão.

A distinção entre "must fix", "suggestion" e "nit"

Uma das contribuições mais práticas que qualquer time pode fazer ao seu processo de code review é adotar uma taxonomia explícita de comentários. Sem isso, o autor do PR precisa advinhar a prioridade de cada comentário — e frequentemente opta pela interpretação mais conservadora (tratar tudo como bloqueante), o que atrasa desnecessariamente a entrega.

Uma taxonomia simples que funciona:

• Bloqueante: precisa ser resolvido antes do merge. Bugs, problemas de segurança, violações de contratos de API, comportamentos incorretos.
• Sugestão: o revisor recomenda a mudança por razões técnicas sólidas, mas o autor pode justificar manter o código como está. A discussão é parte do processo.
• Nit: preferência de estilo ou nomenclatura sem impacto técnico significativo. O autor pode ou não implementar — a decisão é dele. Nits excessivos são um dos maiores desperdiçadores de tempo em code review.
• Pergunta/exploração: o revisor não está pedindo mudança — está curioso sobre a abordagem e quer entender o raciocínio. Não exige resposta em forma de código.

Code review como ferramenta de mentoria

Para devs júniors, o code review é uma das fontes mais ricas de aprendizado técnico — desde que o revisor use a oportunidade deliberadamente. Isso significa não apenas apontar o que está errado, mas explicar os princípios por trás da correção e criar conexão com padrões mais amplos do sistema.

Uma técnica eficiente para mentoria via code review: quando você encontra um padrão problemático, não apenas corrija aquela instância. Escreva um comentário que explique o princípio ("esse padrão de instanciar a dependência dentro do método dificulta testes porque... aqui está como você pode separar isso...") e aponte para onde esse princípio é aplicado de forma exemplar em outros lugares do codebase.

Outro recurso: pair review. Em vez de revisar assincronamente, sente com o dev júnior por 30 minutos e revise o PR juntos, explicando o raciocínio em voz alta. O custo de tempo é maior no curto prazo; o ganho de velocidade de aprendizado é muito mais alto.

Como evitar que o tech lead vire gargalo

A solução mais eficiente para o gargalo de revisão é distribuir a responsabilidade. Isso significa:

• Estabelecer claramente quais tipos de PRs precisam de revisão do tech lead e quais podem ser aprovados por qualquer membro sênior do time
• Investir em desenvolver a capacidade de revisão de todos — não apenas dos sêniores
• Criar um rodízio de revisão onde diferentes pessoas revisam diferentes tipos de trabalho
• Usar pair programming para decisões de design complexas antes de chegar ao PR, reduzindo o tamanho e a complexidade do que precisa ser revisado

Um princípio útil: o tech lead deve ser revisor obrigatório apenas para decisões de arquitetura e mudanças em componentes críticos. Para o restante, sua participação nas revisões é opcional e de alto valor — ele entra quando há discussão técnica que se beneficia da perspectiva dele, não como portão de aprovação.

Automatize o que pode ser automatizado

Linters, formatters, análise estática de segurança, cobertura mínima de testes — tudo isso pode e deve ser automatizado na pipeline de CI. Qualquer comentário de code review que uma ferramenta poderia ter feito é um comentário que consumiu tempo de um ser humano desnecessariamente.

O investimento inicial em configurar essas ferramentas (Prettier, ESLint, SonarQube, Dependabot, CodeQL — dependendo do stack) se paga em semanas de revisões mais focadas. E tem o efeito colateral de remover preferências pessoais de estilo das discussões — quando o formatter decide o formato, não há debate.

Code review para devs sêniores versus júniors

Com júniors, o foco do code review é pedagógico: explicar princípios, conectar escolhas com consequências, construir o modelo mental que o dev vai carregar para o próximo PR. O revisor gasta mais tempo escrevendo comentários contextualizados do que simplesmente marcando problemas.

Com sêniores, a dinâmica muda. O revisor pode questionar abordagens de forma mais direta e esperar que o sênior defenda ou revise sua posição com argumentos técnicos. A revisão de PR de um sênior por outro sênior deve ser uma conversa entre iguais sobre trade-offs, não uma verificação de conformidade com padrões básicos.

Uma boa heurística: se você está explicando coisas básicas em um PR de um sênior, ou o sênior está com sobrecarga e entregou código descuidado (que é um problema de processo diferente), ou as expectativas de nível não estão claras para esse dev.