8 min leitura • Guide 679 of 877
Melhorando Qualidade de Revisão de Código
Revisões de código de alta qualidade pegam bugs, compartilham conhecimento e melhoram qualidade de código através da equipe. GitScrum ajuda a rastrear status de revisão, identificar gargalos de revisão e manter visibilidade no processo de revisão como parte do fluxo de trabalho de desenvolvimento.
Framework de Qualidade de Revisão
O Que Revisar
ÁREAS DE FOCO DA REVISÃO DE CÓDIGO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ALTA PRIORIDADE (Sempre Revisar): │
│ ✓ Correção lógica │
│ ✓ Vulnerabilidades de segurança │
│ ✓ Tratamento de erro │
│ ✓ Casos extremos │
│ ✓ Mudanças que quebram │
│ │
│ PRIORIDADE MÉDIA (Geralmente Revisar): │
│ ✓ Implicações de performance │
│ ✓ Cobertura de teste │
│ ✓ Design de API │
│ ✓ Manutenibilidade de código │
│ ✓ Precisão de documentação │
│ │
│ BAIXA PRIORIDADE (Automatizar Quando Possível): │
│ ○ Formatação e estilo │
│ ○ Ordenação de imports │
│ ○ Convenções de nomenclatura │
│ ○ Regras simples de linting │
│ │
│ AUTOMATIZAR: Use linters, formatters, verificadores de tipo│
│ Revisores humanos focam no que máquinas não podem fazer │
└─────────────────────────────────────────────────────────────┘
Checklist de Revisão
CHECKLIST DO REVISOR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ANTES DE REVISAR: │
│ ☐ Ler descrição do PR e tarefa ligada │
│ ☐ Entender o contexto e objetivo │
│ ☐ Verificar status CI (testes passam?) │
│ │
│ CORREÇÃO: │
│ ☐ Resolve o problema declarado? │
│ ☐ Há erros de lógica? │
│ ☐ Casos extremos são tratados? │
│ ☐ Tratamento de erro é apropriado? │
│ │
│ SEGURANÇA: │
│ ☐ Validação de entrada presente? │
│ ☐ Nenhum dado sensível exposto? │
│ ☐ Autenticação/autorização correta? │
│ ☐ Sem SQL injection, XSS, etc.? │
│ │
│ QUALIDADE: │
│ ☐ Código é legível e manutenível? │
│ ☐ Testes são adequados? │
│ ☐ Sem problemas óbvios de performance? │
│ ☐ Segue padrões da equipe? │
│ │
│ APÓS REVISAR: │
│ ☐ Feedback é construtivo? │
│ ☐ Bloqueador vs não-bloqueador claro? │
│ ☐ Perguntas feitas quando pouco claro? │
└─────────────────────────────────────────────────────────────┘
Qualidade de Feedback
Escrevendo Bons Comentários
GUIA DE QUALIDADE DE FEEDBACK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COMENTÁRIO RUIM: │
│ "Isso está errado." │
│ │
│ COMENTÁRIO MELHOR: │
│ "Isso falhará quando `user` for null. Considere adicionar │
│ uma verificação null na linha 45." │
│ │
│ ───────────────────────────────────────────────── │
│ │
│ COMENTÁRIO RUIM: │
│ "Use um nome melhor." │
│ │
│ COMENTÁRIO MELHOR: │
│ "A variável `d` não está clara. Talvez `daysSinceLogin` │
│ transmitiria o propósito melhor?" │
│ │
│ ───────────────────────────────────────────────── │
│ │
│ COMENTÁRIO RUIM: │
│ "Isso é ineficiente." │
│ │
│ COMENTÁRIO MELHOR: │
│ "Esta abordagem é O(n²) devido a loops aninhados. Para │
│ datasets grandes, considere usar um Map para lookup O(n). │
│ Feliz em discutir se esta complexidade é necessária aqui."│
│ │
│ ───────────────────────────────────────────────── │
│ │
│ CONVENÇÕES DE PREFIXO DE COMENTÁRIO: │
│ [blocking]: Deve corrigir antes do merge │
│ [nit]: Menor, sugestão não-bloqueadora │
│ [question]: Preciso de esclarecimento │
│ [praise]: Ótimo trabalho, continue fazendo isso │
└─────────────────────────────────────────────────────────────┘
Tom Construtivo
DIRETRIZES DE TOM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ USE "NÓS" AO INVÉS DE "VOCÊ": │
│ ✗ "Você deveria usar early return aqui" │
│ ✓ "Preferimos early returns nesta codebase" │
│ │
│ PERGUNTE AO INVÉS DE COMANDAR: │
│ ✗ "Mude isso para usar async/await" │
│ ✓ "O que você acha de usar async/await aqui?" │
│ │
│ EXPLIQUE O PORQUÊ: │
│ ✗ "Adicione tratamento de erro" │
│ ✓ "Adicionando tratamento de erro aqui preveniria falhas │
│ silenciosas que poderiam corromper dados do usuário." │
│ │
│ RECONHEÇA BOM TRABALHO: │
│ ✗ [silêncio em código bom] │
│ ✓ "Bom uso do padrão factory aqui. Solução limpa." │
│ │
│ SEJA ESPECÍFICO: │
│ ✗ "A arquitetura está errada" │
│ ✓ "Isso cria uma dependência circular entre módulos. │
│ Considere extrair a lógica compartilhada para um terceiro│
│ módulo." │
│ │
│ LEMBRE-SE: Revisão de código é ensinar, não julgar │
└─────────────────────────────────────────────────────────────┘
Eficiência de Revisão
Tamanho e Escopo de PR
CARACTERÍSTICAS ÓTIMAS DE PR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DIRETRIZES DE TAMANHO: │
│ │
│ Linhas │ Qualidade de │ Tempo │ Recomendação │
│ │ Revisão │ │ │
│─────────┼─────────────────┼─────────┼──────────────────────│
│ <100 │ Excelente │ 15 min │ ✅ Ideal │
│ 100-400 │ Boa │ 30 min │ ✅ Aceitável │
│ 400-800 │ Declinando │ 60 min │ ⚠️ Divida se possível│
│ 800+ │ Ruim │ 90+ min │ ❌ Deve dividir │
│ │
│ DIRETRIZES DE ESCOPO: │
│ │
│ ✅ ESCOPO BOM DE PR: │
│ • Feature única ou correção de bug │
│ • Uma mudança lógica │
│ • Inclui testes relacionados │
│ • Auto-contido │
│ │
│ ❌ ESCOPO RUIM DE PR: │
│ • Múltiplas mudanças não relacionadas │
│ • Refatoração de "enquanto eu estava aqui" │
│ • Feature + limpeza não relacionada │
│ • Reformatação grande + mudanças de lógica │
│ │
│ REGRA: Se você não consegue descrever o PR em uma frase, │
│ provavelmente deveria ser múltiplos PRs. │
└─────────────────────────────────────────────────────────────┘
Priorização de Revisão
MATRIZ DE PRIORIDADE DE REVISÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ORDEM DE REVISÃO: │
│ │
│ 1. BLOQUEANDO OUTROS │
│ PRs que estão bloqueando outros membros da equipe │
│ → Revisar dentro de 2 horas │
│ │
│ 2. PEQUENO E URGENTE │
│ Correções de bug, hotfixes, sensíveis ao tempo │
│ → Revisar dentro de 4 horas │
│ │
│ 3. AGUARDANDO SEGUNDA REVISÃO │
│ Uma aprovação, precisa de sinal final │
│ → Revisar dentro de 4 horas │
│ │
│ 4. PADRÃO │
│ Trabalho de feature normal │
│ → Revisar dentro de 24 horas │
│ │
│ 5. GRANDE / COMPLEXO │
│ Precisa de tempo dedicado │
│ → Agende sessão de revisão │
│ │
│ HÁBITO DIÁRIO: │
│ Verificar revisões pendentes no início e fim do dia │
│ Mentalidade "Revisar primeiro, codificar segundo" │
└─────────────────────────────────────────────────────────────┘
Métricas e Melhoria
Métricas de Revisão
MÉTRICAS DE REVISÃO DE CÓDIGO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TEMPO PARA PRIMEIRA REVISÃO: │
│ De criação do PR ao primeiro comentário do revisor │
│ Meta: <4 horas | Atual: 6 horas │
│ │
│ TEMPO DE CICLO DE REVISÃO: │
│ De criação do PR à aprovação final │
│ Meta: <24 horas | Atual: 32 horas │
│ │
│ ITERAÇÕES DE REVISÃO: │
│ Número de rodadas de request changes │
│ Meta: ≤2 | Atual: 2.3 │
│ │
│ COMENTÁRIOS POR PR: │
│ Média de comentários construtivos │
│ Meta: 3-10 | Atual: 5.2 │
│ │
│ DEFEITOS ENCONTRADOS NA REVISÃO: │
│ Bugs pegos antes do merge │
│ Rastrear: Severidade de questões encontradas │
│ │
│ COBERTURA DE REVISÃO: │
│ % de código que recebe revisão │
│ Meta: 100% | Atual: 100% │
└─────────────────────────────────────────────────────────────┘