6 min leitura • Guide 634 of 877
Melhores práticas de revisão de código
Revisões de código efetivas equilibram rigor com velocidade, capturando problemas importantes enquanto evitam gargalos de revisão que desaceleram entrega. Integração do GitScrum com ferramentas de revisão de código ajuda equipes rastrearem status de revisão, identificarem gargalos e garantirem que revisões aconteçam prontamente sem bloquear desenvolvedores.
Design de processo de revisão
SLAs de revisão
NÍVEIS DE SERVIÇO DE REVISÃO DE CÓDIGO:
┌─────────────────────────────────────────────────────────────┐
│ MÉTRICA │ META │ AÇÃO SE PERDIDO │
├─────────────────────────┼─────────────┼─────────────────────┤
│ Primeira resposta │ < 4 horas │ Lembrete no Slack │
│ Revisão completa │ < 24 horas │ Escalar para líder │
│ Merge PR após aprovação │ < 2 horas │ Autor notificado │
│ Resposta de revisão │ < 4 horas │ Aumento de prioridade│
└─────────────────────────────────────────────────────────────┘
Rastrear no GitScrum:
• Dashboard mostra tempo médio de revisão
• Alertas para PRs estagnados
• Métricas da equipe para velocidade de revisão
Diretrizes de tamanho PR
TAMANHO ÓTIMO DE PR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LINHAS DE CÓDIGO │ TEMPO DE REVISÃO │ DETECÇÃO DE DEFEITO │
├───────────────┼─────────────┼───────────────────────────────┤
│ < 200 │ 15-30 min │ Alta - revisão thorough │
│ 200-400 │ 30-60 min │ Boa - revisão efetiva │
│ 400-800 │ 1-2 horas │ Média - fadiga do revisor │
│ > 800 │ 2+ horas │ Baixa - revisão superficial │
└───────────────────────────────────────────────────────────────┘
ESTRATÉGIAS PARA PRs MENORES:
• Ship refactoring separadamente de features
• Dividir features grandes em mudanças incrementais
• Usar feature flags para implementações parciais
• Separar adições de teste de mudanças de código
Qualidade de revisão
O que procurar
CHECKLIST DE REVISÃO DE CÓDIGO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CORREÇÃO: │
│ □ Faz o que deveria fazer? │
│ □ Casos extremos tratados? │
│ □ Condições de erro cobertas? │
│ │
│ DESIGN: │
│ □ A abordagem é apropriada? │
│ □ Cabe na arquitetura? │
│ □ É manutenível? │
│ │
│ LEGIBILIDADE: │
│ □ Nomenclatura clara? │
│ □ Comentários apropriados? │
│ □ Complexidade razoável? │
│ │
│ TESTE: │
│ □ Testes incluídos? │
│ □ Cobertura de teste adequada? │
│ □ Casos extremos testados? │
│ │
│ SEGURANÇA: │
│ □ Nenhum dado sensível exposto? │
│ □ Validação de entrada presente? │
│ □ Autenticação/autorização correta? │
└─────────────────────────────────────────────────────────────┘
Feedback construtivo
COMENTÁRIOS DE REVISÃO EFETIVOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EM VEZ DE: TENTE: │
├───────────────────────────────┼─────────────────────────────┤
│ "Isso está errado" │ "Isso pode causar X. │
│ │ Considere Y ao invés?" │
├───────────────────────────────┼─────────────────────────────┤
│ "Nomenclatura ruim" │ "Que tal `userCount` │
│ │ para clareza?" │
├───────────────────────────────┼─────────────────────────────┤
│ "Por que você fez isso?" │ "Estou curioso sobre o │
│ │ raciocínio aqui - pode │
│ │ explicar?" │
└─────────────────────────────────────────────────────────────┘
PREFIXOS DE COMENTÁRIO:
[nit] - Preferência de estilo menor, opcional
[suggestion] - Considere esta abordagem
[question] - Precisa de esclarecimento
[blocker] - Deve corrigir antes do merge
Fluxo de trabalho de revisão
Integração GitScrum
CICLO DE VIDA PR → TAREFA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ATUALIZAÇÕES AUTOMATIZADAS DE STATUS: │
│ │
│ PR Criado → Tarefa move para "Em Revisão" │
│ Revisão Feita → Tarefa mostra badge "Aprovado" │
│ Mudanças Req → Tarefa mostra "Mudanças Solicitadas" │
│ PR Merged → Tarefa move para "Feito" │
│ │
│ VISUALIZAÇÃO DE TAREFA GITSCRUM: │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Tarefa #234: Autenticação de Usuário │ │
│ │ Status: Em Revisão │ │
│ │ │ │
│ │ PR Vinculado: #456 - Implementar fluxo de login │ │
│ │ ✓ CI Passou | 👀 2 revisores | 💬 5 comentários │ │
│ │ Última atividade: 2 horas atrás │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Atribuição de revisão
SELEÇÃO DE REVISOR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ATRIBUIÇÃO AUTOMÁTICA: │
│ • Round-robin entre equipe │
│ • Proprietários de código para caminhos específicos │
│ • Baseado em tags de expertise │
│ │
│ CONSIDERAÇÕES: │
│ • Balancear carga de revisão entre equipe │
│ • Incluir especialista de domínio para mudanças complexas │
│ • Devs juniores revisam para aprendizado │
│ • Senior revisa para caminhos críticos │
│ │
│ RASTREAMENTO GITSCRUM: │
│ • Carga de revisão por membro da equipe │
│ • Tempo médio de revisão por revisor │
│ • Métricas de qualidade de revisão │
└─────────────────────────────────────────────────────────────┘
Medindo efetividade de revisão
Métricas de revisão
MÉTRICAS PRINCIPAIS DE REVISÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MÉTRICAS DE PROCESSO: │
│ • Tempo para primeira revisão: 3.2 horas média │
│ • Tempo para merge: 18 horas média │
│ • Ciclos de revisão: 1.3 média │
│ │
│ MÉTRICAS DE QUALIDADE: │
│ • Problemas encontrados em revisão: 2.1 por PR média │
│ • Bugs pós-merge: 0.3 por PR média │
│ • Taxa de escape de revisão: 5% │
│ │
│ SAÚDE DA EQUIPE: │
│ • Participação em revisão: 85% da equipe │
│ • Distribuição de carga: Uniforme (±15%) │
│ • Tom de comentário: Construtivo │
└─────────────────────────────────────────────────────────────┘