Dominando Code Reviews: Um Guia para Revisores e Autores

Se você perguntar a um desenvolvedor júnior qual é o trabalho dele, ele dirá "escrever código". Se perguntar a um sênior, ele dirá "resolver problemas". Mas se perguntar a um Staff Engineer, ele pode dizer "ler e revisar código".

À medida que você cresce na carreira, passará mais tempo lendo código do que escrevendo. Code review (revisão de código) é o mecanismo mais importante para manter a qualidade do código, compartilhar conhecimento e mentorar membros da equipe.

No entanto, muitas vezes é uma fonte de ansiedade. Autores temem críticas; revisores temem conflitos. Este guia explora como transformar code reviews de uma tarefa dolorosa em um superpoder para sua equipe.

A Filosofia: Não É Sobre Você

A primeira regra do code review é: Estamos criticando o código, não a pessoa.

Ruim: "Você quebrou o build com essa mudança."
Bom: "Essa mudança parece causar uma falha no build."

Parece uma mudança semântica sutil, mas muda a dinâmica de acusação para colaboração.

Para Autores: A Arte do Pull Request

Um ótimo code review começa antes de você abrir o PR. Seu objetivo é tornar o trabalho do revisor o mais fácil possível.

1. Contexto é Rei

Nunca abra um PR com uma descrição em branco. No mínimo, inclua:

O que essa mudança faz?
Por que é necessária? (Link para o ticket/issue)
Como foi testada? (Screenshots, vídeos ou saída do CLI)

2. O Tamanho "Cachinhos Dourados"

Um estudo da Cisco Systems descobriu que a capacidade de um revisor de encontrar defeitos cai significativamente após revisar 200-400 linhas de código de uma vez.

Muito Pequeno: Corrigir um erro de digitação (a menos que seja urgente).
Muito Grande: "Refatoração de todo o sistema de autenticação" (2.000 linhas).
Na Medida: Uma unidade lógica de trabalho (ex: "Adicionar endpoint de login de usuário").

Se seu PR for muito grande, empilhe-o (stack it). Quebre-o em PRs menores e dependentes.

3. Auto-Revisão (Self-Review)

Antes de atribuir um revisor, leia seu próprio diff. Você ficará surpreso com quantos erros bobos (console.logs, código comentado) você mesmo encontra. Um diff limpo mostra respeito pelo tempo do seu revisor.

Para Revisores: O Que Procurar

Quando você abrir uma revisão, não procure apenas ponto e vírgula faltando. Pense em camadas.

Camada 1: Arquitetura e Design (O "Panorama Geral")

Essa mudança pertence a este lugar?
É escalável?
Introduz dívida técnica?
Ação: Se o design estiver errado, pare de revisar os detalhes. Discuta a abordagem primeiro.

Camada 2: Funcionalidade e Bugs

Realmente funciona?
Casos de borda são tratados? (Null checks, listas vazias, estados de erro)
Existe alguma vulnerabilidade de segurança? (SQL injection, XSS)

Camada 3: Legibilidade e Manutenibilidade

Os nomes das variáveis são descritivos? (x vs userIndex)
A lógica é muito complexa? (Loops aninhados, funções massivas)
Um desenvolvedor daqui a seis meses entenderá isso?

Camada 4: Estilo e Nits (A Camada "Automatizada")

Indentação, espaçamento, parênteses.
Pro Tip: Automatize isso com Prettier/ESLint. Humanos não deveriam perder tempo discutindo sobre vírgulas.

A Armadilha do "Nitpick"

Todos nós já passamos por isso. Você envia um algoritmo complexo e o revisor comenta: "Por favor, adicione uma nova linha no final do arquivo."

Embora o estilo importe, focar apenas em nits (detalhes menores) é desmoralizante. Parece "bike-shedding".

A Regra de Ouro:
Se um comentário for puramente subjetivo ou uma preferência menor, rotule-o como "Nit" ou "Non-blocking".

"Nit: Eu prefiro const aqui, mas sinta-se à vontade para ignorar."

Isso sinaliza para o autor: "Eu aprovo sua lógica, isso é apenas uma sugestão de polimento."

Lidando com Desacordos

Desacordos são saudáveis. Significam que as pessoas se importam. Mas podem se tornar tóxicos se mal administrados.

Faça Perguntas, Não Dê Ordens:
- Em vez de: "Mova isso para uma função utilitária."
- Tente: "O que você acha de mover isso para uma função utilitária para melhorar a reutilização?"
Entre em uma Chamada:
- Se uma thread de comentários vai e volta mais de 3 vezes, pare de digitar. Entre em uma videochamada ou vá até a mesa da pessoa. Texto é um meio terrível para nuances.
Disagree and Commit (Discordar e Comprometer-se):
- Às vezes não há resposta "certa". Se o autor tem uma razão válida e não é um problema crítico, deixe passar. A confiança é mais importante do que estar 100% certo.

Conclusão

Code review é uma habilidade, assim como codificar. Requer empatia, clareza e paciência.

Autores: Escrevam PRs ricos em contexto e respeitem o tempo do seu revisor.
Revisores: Procurem problemas arquiteturais primeiro, sejam gentis e distingam entre "deve corrigir" e "seria bom ter".

Quando feito corretamente, code review não produz apenas código melhor; produz engenheiros melhores.