Code review: o que procurar e como dar feedback

1. Por que code review importa no fluxo Git

Code review é uma das práticas mais valiosas em times que utilizam Git. Quando feita corretamente, ela atua como uma barreira de qualidade antes que o código seja mesclado à branch principal. No contexto do Git, cada Pull Request (PR) representa uma proposta de alteração no histórico do repositório — e revisar esse PR significa garantir que o histórico permaneça limpo, seguro e compreensível.

Os benefícios são concretos:
- Redução de bugs antes do merge: problemas são identificados antes de afetarem outros desenvolvedores ou ambientes de produção.
- Compartilhamento de conhecimento: o revisor aprende sobre áreas do código que não conhecia, e o autor recebe feedback que melhora sua prática.
- Manutenção da qualidade: o repositório mantém consistência de estilo, lógica e arquitetura.

2. Preparação do revisor: o que analisar antes de comentar

Antes de abrir o diff e começar a comentar, o revisor deve se preparar. Uma revisão eficiente começa com o entendimento do contexto:

git checkout main
git pull origin main
git checkout -b review-branch origin/nome-da-branch
git log main..HEAD --oneline

Esse fluxo permite visualizar exatamente quais commits foram adicionados. Em seguida, verifique:

  • Se o CI está passando: não faz sentido revisar código que já quebra os testes.
  • Se o PR é focado: um PR que altera 30 arquivos com correções de bug, refatoração e nova funcionalidade é difícil de revisar e propenso a erros.
  • Se a descrição do PR explica o "porquê": um bom PR deve responder "o que foi feito" e "por que foi feito dessa forma".

3. O que procurar: aspectos técnicos no código

Durante a leitura do diff, concentre-se em:

Lógica e erros de borda: condições que podem quebrar em cenários inesperados.

# Exemplo de problema: divisão por zero não tratada
def calcular_media(valores):
    return sum(valores) / len(valores)  # O que acontece se a lista for vazia?

Tratamento de exceções e recursos: vazamento de conexões, arquivos não fechados, falta de tratamento de erros em operações críticas.

Uso correto de padrões: se o time adota injeção de dependência, testes unitários ou determinada arquitetura, verifique se o código segue essas convenções.

4. O que procurar: aspectos de Git e histórico

O código não é a única coisa sendo revisada — o histórico de commits também importa. Um PR bem construído facilita revisões futuras e bissecção de bugs.

Commits atômicos e mensagens claras:

# Ruim
commit 1: "wip"
commit 2: "fix"
commit 3: "final"

# Bom
commit 1: "feat: adiciona endpoint de login"
commit 2: "test: adiciona testes para validação de senha"
commit 3: "refactor: extrai lógica de hash para serviço separado"

Ausência de merge commits desnecessários: um PR que contém merges da main sugere que o autor não fez rebase corretamente.

# O que o revisor vê no log
*   Merge branch 'main' into feature-x
|\
| * commit abc123 (main)
* | commit def456 (feature-x)
|/
* commit 789ghi

Nesse caso, peça um rebase:

git rebase main

Arquivos sensíveis ou desnecessários: verifique se não há arquivos como .env, node_modules/, *.log ou credenciais commitadas. Use um .gitignore adequado.

5. Como dar feedback construtivo

A forma como o feedback é dado determina se ele será bem recebido ou ignorado. Prefira perguntas a afirmações categóricas:

# Em vez de:
"Está errado. Isso vai quebrar."

# Prefira:
"O que acontece se a lista estiver vazia? Talvez possamos adicionar uma validação antes da divisão."

Apontar o problema e sugerir solução:

# Comentário no PR
A função `calcular_media` não trata o caso de lista vazia, o que resultará em `ZeroDivisionError`.
Sugestão: adicionar uma verificação no início:
    if not valores:
        return 0.0

Separar críticas técnicas de estilo: se o time tem um linter configurado, use-o. Comentários sobre indentação ou nomes de variáveis devem seguir a convenção acordada, não a preferência pessoal do revisor.

6. Boas práticas de comunicação no Pull Request

Comentários específicos nas linhas: evite comentários genéricos no corpo do PR. Use a funcionalidade de comentários em linha do GitHub/GitLab para apontar exatamente onde o problema está.

# Ruim (no corpo do PR)
"Tem um bug na função de cálculo."

# Bom (na linha específica)
"Aqui, se a lista estiver vazia, ocorrerá divisão por zero.
Sugiro adicionar uma validação."

Evitar linguagem agressiva: foque no código, não na pessoa. Use "nós" em vez de "você".

# Evite
"Você esqueceu de tratar o caso de borda."

# Prefira
"Precisamos tratar o caso de borda aqui para evitar erro em produção."

Agradecer e destacar acertos: um PR não é apenas sobre apontar problemas. Reconheça boas soluções:

"Ótima abordagem usar cache aqui! Isso vai melhorar a performance significativamente."

7. Quando aprovar, solicitar mudanças ou discutir

Aprovar quando:
- O código funciona corretamente e está testado.
- Segue os padrões do time.
- Não há bugs ou problemas de segurança.
- O histórico de commits está limpo.

Solicitar mudanças quando:
- Há bugs ou vulnerabilidades.
- O código quebra contratos existentes (API, banco de dados).
- Testes estão ausentes para funcionalidades críticas.
- Há arquivos sensíveis commitados.

Discutir quando:
- Há divergência de abordagem técnica sem consenso claro.
- O autor propõe uma solução que foge dos padrões, mas pode ser válida.
- O escopo do PR cresceu além do original.

Nesses casos, marque o PR como "comentário" ou inicie uma discussão com o time antes de bloquear o merge.

Referências