Diretrizes de revisão de código

Revisões de código capturam bugs, compartilham conhecimento e melhoram qualidade de código. Boas revisões são colaborativas e educacionais. Más revisões são lentas, excessivamente críticas ou apenas aprovadas. Este guia cobre práticas efetivas de revisão de código.

Áreas de foco de revisão

Processo de revisão

Submetendo revisões

PROCESSO DE REVISÃO DE CÓDIGO
════════════════════════════

ANTES DE SUBMETER PR:
─────────────────────────────────────
Autor deve:
├── Auto-revisar primeiro
├── Executar testes localmente
├── Verificar linting passa
├── Escrever descrição clara
├── Vincular à issue/ticket
├── Manter PR pequeno (< 400 linhas ideal)
└── PR preparado

DESCRIÇÃO PR:
─────────────────────────────────────
Incluir:
├── O que: Resumo das mudanças
├── Por que: Contexto e motivação
├── Como: Abordagem tomada
├── Teste: Como foi testado
├── Screenshots: Se mudança UI
└── Contexto completo

SELEÇÃO DE REVISOR:
─────────────────────────────────────
├── Especialista de domínio
├── Alguém não familiar (olhos frescos)
├── Não sempre mesma pessoa
├── Rotacionar revisores
├── Balancear carga
└── Revisores certos

CRONOGRAMA DE REVISÃO:
─────────────────────────────────────
├── Solicitar revisão → Dentro de 24 horas
├── Feedback endereçado → Mesmo dia se pequeno
├── Não bloqueando por dias
├── Atenção prioritária
└── Loop de feedback rápido

Dando revisões

Feedback efetivo

DANDO REVISÕES
══════════════

O QUE PROCURAR:
─────────────────────────────────────
Alta prioridade:
├── Correção: Funciona?
├── Casos extremos: O que pode quebrar?
├── Segurança: Alguma vulnerabilidade?
├── Design: É manutenível?
├── Teste: Testes são adequados?
└── Problemas importantes

Prioridade menor:
├── Performance (a menos que caminho crítico)
├── Problemas menores de estilo
├── Detalhes
├── Preferências pessoais
└── Deixe automação cuidar

COMO DAR FEEDBACK:
─────────────────────────────────────
Pergunte:
├── "O que acontece se X é null?"
├── "Você considerou abordagem Y?"
├── "Isso pode ser simplificado?"
└── Tom colaborativo

Explique por que:
├── Não: "Use X ao invés de Y"
├── Mas: "X seria mais claro aqui porque..."
├── Entendimento, não ordens
└── Educacional

Rotule feedback:
├── [Deve corrigir]: Problemas bloqueantes
├── [Sugestão]: Melhorias opcionais
├── [Nit]: Muito menor, não bloqueante
├── [Pergunta]: Buscando entendimento
└── Expectativas claras

EXEMPLO DE BOM FEEDBACK:
─────────────────────────────────────
"[Sugestão] Considere extrair esta
lógica para uma função separada—iria
facilitar teste e tornar a função
principal mais legível. Feliz em
discutir se você vê diferente!"

FEEDBACK RUIM:
─────────────────────────────────────
├── "Errado"
├── "Não faça isso"
├── "???"
├── Não útil, pouco claro
└── Evite estes

ELOGIE CÓDIGO BOM:
─────────────────────────────────────
├── "Bom refactor aqui!"
├── "Ótima cobertura de teste"
├── "Solução esperta"
├── Reconhecimento importa
└── Não apenas crítica

Cultura de revisão

Dinâmicas saudáveis

CULTURA DE REVISÃO
══════════════════

PRINCÍPIOS:
─────────────────────────────────────
├── Revise código, não pessoas
├── Assuma boa intenção
├── Colaborativo, não adversarial
├── Oportunidade de aprendizado
├── Código de todos é revisado
├── Incluindo seniors
└── Cultura saudável

EVITE:
─────────────────────────────────────
├── Detalhes excessivos em problemas menores
├── Demandar preferências de estilo
├── Bloquear por razões triviais
├── Ser rude ou condescendente
├── Aprovação automática (sem revisão)
├── Levar crítica pessoalmente
└── Anti-padrões

RESOLVA DESACORDOS:
─────────────────────────────────────
├── Discuta sincronamente se travado
├── Foque no código, não ego
├── Escalate se necessário
├── Aceite quando estiver errado
├── Siga em frente
└── Resolução profissional

AUTOMAÇÃO:
─────────────────────────────────────
Deixe ferramentas cuidarem:
├── Formatação (Prettier, Black)
├── Linting (ESLint, Pylint)
├── Verificação de tipo
├── Execução de teste
├── Varredura de segurança
├── Humanos focam em lógica
└── Uso eficiente de tempo

Integração GitScrum

Vinculando revisões ao trabalho

GITSCRUM PARA REVISÕES
══════════════════════

VINCULAÇÃO DE TAREFA:
─────────────────────────────────────
├── Vincular PR à tarefa GitScrum
├── Atualizar status da tarefa
├── Rastreabilidade
├── O que foi enviado quando
└── Fluxo de trabalho conectado

DEFINIÇÃO DE PRONTO:
─────────────────────────────────────
DoD inclui:
├── ☐ PR submetido
├── ☐ Código revisado
├── ☐ Feedback endereçado
├── ☐ Aprovado
├── ☐ Merged
└── Revisão requerida

MÉTRICAS DE REVISÃO:
─────────────────────────────────────
Rastreie:
├── Tempo para revisar
├── Profundidade de revisão
├── Ciclos de revisão
├── Identificar gargalos
└── Melhoria de processo

Melhores práticas

Para revisões de código

1. Revisões oportunas — Dentro de 24 horas
2. PRs pequenos — Mais fáceis de revisar bem
3. Tom construtivo — Perguntas sobre demandas
4. Foco na substância — Não detalhes de estilo
5. Automatize estilo — Humanos revisam lógica

Anti-padrões

ERROS DE REVISÃO:
✗ Levando dias para revisar
✗ PRs gigantes
✗ Aprovação automática
✗ Detalhes excessivos em estilo
✗ Comentários condescendentes
✗ Sem explicações
✗ Bloqueando trivialmente
✗ Nunca elogiando

Soluções Relacionadas

• Melhores práticas de integração contínua
• Rastreamento de qualidade de código
• Práticas de programação em par