5 min leitura • Guide 654 of 877
Otimização de processo de revisão de código
Revisões de código são cruciais para qualidade de código e compartilhamento de conhecimento, mas processos ruins criam gargalos frustrantes. GitScrum ajuda rastrear status de revisão, identificar backlogs de revisão e medir tempos de resposta de revisão para ajudar equipes otimizarem seus fluxos de trabalho de revisão.
Design de processo de revisão
Estágios de fluxo de trabalho
PIPELINE DE REVISÃO DE CÓDIGO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PR CRIADO → PRONTO PARA REVISÃO → EM REVISÃO → APROVADO │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ [Esperando] [Ativo] [Merge] │
│ Meta: <4h Meta: <24h Meta: <2h │
│ │
├─────────────────────────────────────────────────────────────┤
│ │
│ ESTADO ATUAL: │
│ Pronto para Revisão: 3 PRs (mais antigo: 2h) ✅ Saudável│
│ Em Revisão: 2 PRs ✅ Saudável │
│ Aprovado: 1 PR (esperando merge) ✅ Saudável │
│ │
│ ALERTAS: │
│ ⚠️ PR #234 esperando 6h (SLA excedido) │
│ │
└─────────────────────────────────────────────────────────────┘
SLAs de revisão
EXPECTATIVAS DE REVISÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRIORIDADE │ PRIMEIRA RESPOSTA │ CONCLUSÃO │ ESCALAÇÃO │
│────────────┼───────────────────┼───────────┼────────────────│
│ Crítico │ 2 horas │ 4 horas │ Após 3h │
│ Alto │ 4 horas │ 24 horas │ Após 6h │
│ Normal │ 24 horas │ 48 horas │ Após 36h │
│ Baixo │ 48 horas │ 72 horas │ Após 60h │
│ │
│ TIPOS DE RESPOSTA: │
│ • Aprovar: Pronto para merge │
│ • Comentar: Perguntas/sugestões (não bloqueante) │
│ • Solicitar Mudanças: Deve endereçar antes do merge │
│ │
│ QUANDO SOLICITAR MUDANÇAS: │
│ • Vulnerabilidades de segurança │
│ • Mudanças breaking sem migração │
│ • Testes faltando para caminhos críticos │
│ • Bugs claros na lógica │
└─────────────────────────────────────────────────────────────┘
Melhores práticas de Pull Request
Diretrizes de tamanho PR
TAMANHO ÓTIMO DE PR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LINHAS │ TEMPO DE REVISÃO │ QUALIDADE │ RECOMENDAÇÃO │
│───────────┼──────────────────┼─────────────┼─────────────────│
│ <100 │ 15-30 min │ Excelente │ ✅ Ideal │
│ 100-400 │ 30-60 min │ Boa │ ✅ Aceitável │
│ 400-800 │ 60-90 min │ Declinando │ ⚠️ Considere dividir│
│ 800+ │ 90+ min │ Ruim │ ❌ Muito grande │
│ │
│ ESTRATÉGIAS PARA PRs MENORES: │
│ │
│ 1. Feature flags │
│ Ship features incompletas atrás de flags │
│ │
│ 2. PRs empilhados │
│ PR 1: Modelo de dados → PR 2: API → PR 3: UI │
│ │
│ 3. Extrair refactoring │
│ Refactor primeiro, feature segundo │
│ │
│ 4. Fatias verticais │
│ Ship feature fina end-to-end │
└─────────────────────────────────────────────────────────────┘
Template de descrição PR
TEMPLATE PR:
┌─────────────────────────────────────────────────────────────┐
│ ## O que │
│ [Descrição de uma linha da mudança] │
│ │
│ ## Por que │
│ [Contexto: problema sendo resolvido, link para tarefa] │
│ │
│ ## Como │
│ [Abordagem técnica breve, decisões chave] │
│ │
│ ## Teste │
│ - [ ] Testes unitários adicionados/atualizados │
│ - [ ] Teste manual completado │
│ - [ ] Casos extremos considerados │
│ │
│ ## Screenshots (se mudança UI) │
│ [Screenshots antes/depois] │
│ │
│ ## Foco da Revisão │
│ [O que gostaria que revisores focassem] │
│ │
│ ## Checklist │
│ - [ ] Auto-revisado │
│ - [ ] Testes passam │
│ - [ ] Documentação atualizada │
└─────────────────────────────────────────────────────────────┘
Eficiência de revisão
Automação primeiro
VERIFICAÇÕES AUTOMATIZADAS (antes de revisão humana):
┌─────────────────────────────────────────────────────────────┐
│ │
│ PIPELINE CI: │
│ ✓ Lint - Verificações de estilo de código │
│ ✓ Verificação tipo - Erros TypeScript │
│ ✓ Testes unitários - Suíte de teste automatizada │
│ ✓ Build - Compilação sucede │
│ ✓ Varredura segurança - Vulnerabilidades conhecidas │
│ │
│ BENEFÍCIO: Humanos revisam lógica, não formatação │
│ │
│ CODEOWNERS: │
│ # Atribuir revisores automaticamente por caminho │
│ /api/* @backend-team │
│ /frontend/* @frontend-team │
│ /security/* @security-team │
│ *.sql @dba-team │
│ │
│ COMENTÁRIOS BOT: │
│ • Relatório de cobertura │
│ • Mudança de tamanho de bundle │
│ • Impacto de performance │
└─────────────────────────────────────────────────────────────┘
Reuniões de revisão
PARELHA DE REVISÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUANDO FAZER REVISÃO EM PARELHA (síncrono): │
│ • Mudanças arquiteturais complexas │
│ • Código sensível à segurança │
│ • PRs de desenvolvedor júnior (oportunidade de ensino) │
│ • Dependências cross-team │
│ │
│ QUANDO ASSÍNCRONO É BOM: │
│ • PRs pequenos bem documentados │
│ • Padrões padrão │
│ • Correções de bug com testes claros │
│ │
│ HORA DE REVISÃO (Prática da Equipe): │
│ Diariamente 14-15h: Equipe revisa PRs pendentes juntos │
│ │
│ Benefícios: │
│ • PRs não envelhecem │
│ • Compartilhamento de conhecimento │
│ • Qualidade de revisão consistente │
└─────────────────────────────────────────────────────────────┘