10 min leitura • Guide 35 of 877
Configurando Workflows Efetivos de Code Review
Code reviews são críticos para manter qualidade, compartilhar conhecimento e detectar bugs antes de produção. Mas processos de revisão mal projetados podem se tornar gargalos que frustram desenvolvedores e desaceleram entregas. As integrações e features de workflow do GitScrum ajudam a estabelecer práticas de revisão que são completas mas eficientes.
O Desafio do Code Review
Problemas comuns de revisão:
| Problema | Impacto |
|---|---|
| Reviews demoram muito | PRs acumulam, contexto perdido |
| Padrões inconsistentes | Qualidade varia por revisor |
| Expectativas pouco claras | Nitpicking vs. feedback importante |
| Gargalos de revisores | Uma pessoa bloqueia todos PRs |
| Sem responsabilidade | Reviews ignorados ou atrasados |
Configuração de Integração GitScrum
Conectando Provedores Git
Integração Provedor Git:
PLATAFORMAS SUPORTADAS:
├── GitHub (Cloud & Enterprise)
├── GitLab (Cloud & Self-hosted)
└── Bitbucket (Cloud & Server)
PASSOS DE CONEXÃO:
1. Settings → Integrations → Git Providers
2. Selecionar provedor
3. Autorizar conexão OAuth
4. Escolher repositórios para conectar
5. Configurar ajustes de sincronização
OPÇÕES DE SYNC:
┌─────────────────────────────────────────────────────────────┐
│ Configuração Integração Git │
├─────────────────────────────────────────────────────────────┤
│ Repositório: acme/frontend │
│ │
│ Ajustes de Sync: │
│ ☑ Vincular branches a tarefas (padrão: TASK-###) │
│ ☑ Vincular PRs a tarefas │
│ ☑ Atualizar status de tarefa em eventos PR │
│ ☑ Mostrar status PR em detalhes de tarefa │
│ ☑ Importar comentários PR como comentários de tarefa │
│ │
│ Mapeamento de Status: │
│ PR Aberto → Mover tarefa para: [Em Revisão ▼] │
│ PR Aprovado → Mover tarefa para: [Aprovado ▼] │
│ PR Mergeado → Mover tarefa para: [Feito ▼] │
│ PR Fechado → Mover tarefa para: [Sem mudança ▼] │
└─────────────────────────────────────────────────────────────┘
Vinculação Automática de Tarefas
Convenção de Nomes de Branch:
PADRÃO: [tipo]/TASK-[id]-[descrição]
Exemplos:
├── feature/TASK-456-user-search
├── fix/TASK-789-login-bug
├── refactor/TASK-101-cleanup-auth
└── chore/TASK-202-update-deps
Fluxo de Auto-Detecção:
┌─────────────────────────────────────────────────────────────┐
│ 1. Developer cria branch: │
│ git checkout -b feature/TASK-456-user-search │
│ │
│ 2. GitScrum detecta padrão "TASK-456" │
│ │
│ 3. Tarefa TASK-456 auto-atualizada: │
│ ├── Status: → Em Progresso │
│ ├── Branch: feature/TASK-456-user-search │
│ └── Atividade: "Branch criada por @alice" │
│ │
│ 4. Quando PR é aberto: │
│ ├── PR vinculado à tarefa │
│ ├── Status: → Em Revisão │
│ └── Atividade: "PR #123 aberto" │
│ │
│ 5. Quando PR é mergeado: │
│ ├── Status: → Feito │
│ └── Atividade: "PR #123 mergeado para main" │
└─────────────────────────────────────────────────────────────┘
Atribuição de Revisores
Regras de Atribuição Automatizada
Configuração de Atribuição de Revisores:
ESTRATÉGIAS DE ATRIBUIÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ Regras de Atribuição de Revisores │
├─────────────────────────────────────────────────────────────┤
│ │
│ Estratégia: [Round Robin ▼] │
│ │
│ Opções: │
│ ├── Round Robin: Rotacionar entre membros do time │
│ ├── Load Balanced: Atribuir a pessoa com menos reviews │
│ ├── Code Ownership: Baseado em paths de arquivo alterados │
│ ├── Aleatório: Seleção random do pool │
│ └── Manual: Autor seleciona, com sugestões │
│ │
│ Pool de Revisores: [Time Frontend ▼] │
│ ├── @alice (senior) │
│ ├── @bob (senior) │
│ ├── @carol (mid) │
│ └── @david (mid) │
│ │
│ Revisores Requeridos: [2] │
│ │
│ Regras: │
│ ☑ Pelo menos 1 revisor senior │
│ ☑ Não pode revisar seus próprios PRs │
│ ☑ Excluir em PTO (sync do calendário) │
│ □ Requerer revisor específico para [security/*] │
└─────────────────────────────────────────────────────────────┘
Mapeamento de Ownership de Código
Atribuição estilo CODEOWNERS:
Regras de Path de Arquivo:
┌─────────────────────────────────────────────────────────────┐
│ Configuração de Ownership de Código │
├─────────────────────────────────────────────────────────────┤
│ │
│ Padrão Path Owners Requerido │
│ ───────────────────────────────────────────────────────────│
│ /src/api/* @api-team 1 │
│ /src/components/ui/* @ui-team 1 │
│ /src/auth/* @security-team 2 │
│ /src/payments/* @payments-lead 1 + @security │
│ /database/* @dba-team 1 │
│ *.sql @dba-team 1 │
│ /tests/* @qa-lead Opcional │
│ * @default-reviewers 1 │
│ │
│ Prioridade: Primeira correspondência ganha (cima para baixo)│
└─────────────────────────────────────────────────────────────┘
Balanceamento de Carga de Reviews
Atribuição Balanceada por Carga:
CARGA DE REVIEW ATUAL:
┌─────────────────────────────────────────────────────────────┐
│ CARGA DE TRABALHO REVISORES [Esta Semana] │
├─────────────────────────────────────────────────────────────┤
│ │
│ Reviews Ativos: │
│ Alice: [██░░░░░░] 2 PRs (capacidade: 4) ← Próx atribuir│
│ Bob: [████░░░░] 4 PRs (capacidade: 4) Cheio │
│ Carol: [███░░░░░] 3 PRs (capacidade: 4) │
│ David: [██░░░░░░] 2 PRs (capacidade: 4) ← Próx atribuir│
│ │
│ Stats de Review Esta Semana: │
│ ├── Alice: 8 completados, avg 4h resposta │
│ ├── Bob: 6 completados, avg 6h resposta │
│ ├── Carol: 7 completados, avg 3h resposta │
│ └── David: 5 completados, avg 8h resposta │
└─────────────────────────────────────────────────────────────┘
SLAs de Review e Tracking
Expectativas Baseadas em Tempo
Configuração de SLA de Review:
┌─────────────────────────────────────────────────────────────┐
│ SLAs de Code Review │
├─────────────────────────────────────────────────────────────┤
│ │
│ SLA Primeira Resposta: │
│ ├── P0/Crítico: 2 horas │
│ ├── P1/Alto: 4 horas │
│ ├── P2/Normal: 8 horas (1 dia útil) │
│ └── P3/Baixo: 24 horas │
│ │
│ SLA Conclusão de Review: │
│ ├── PR Pequeno (<100 linhas): 4h após primeira resposta │
│ ├── PR Médio (100-500 linhas): 8 horas │
│ └── PR Grande (>500 linhas): 24 horas │
│ │
│ Regras de Escalação: │
│ ├── 50% do SLA: Lembrete ao revisor │
│ ├── 100% do SLA: Notificar team lead │
│ ├── 150% do SLA: Escalar para eng manager │
│ └── 200% do SLA: Permitir merge sem review completo │
└─────────────────────────────────────────────────────────────┘
Dashboard de Status de Review
Dashboard Pipeline de Review:
┌─────────────────────────────────────────────────────────────┐
│ PIPELINE CODE REVIEW [Últimos 7 Dias ▼] │
├─────────────────────────────────────────────────────────────┤
│ │
│ Status Atual: │
│ ├── Aguardando Review: 8 PRs │
│ ├── Em Review: 5 PRs │
│ ├── Mudanças Solicitadas: 3 PRs │
│ └── Aprovados (pendente merge): 2 PRs │
│ │
│ Performance de SLA: │
│ │ Primeira Resposta │
│ │ No Prazo: ████████████████████ 85% │
│ │ Atrasado: ████ 15% │
│ │ │
│ │ Conclusão de Review │
│ │ No Prazo: ██████████████████ 78% │
│ │ Atrasado: ██████ 22% │
│ │
│ PRs com Risco de SLA: │
│ ├── 🔴 PR #456: 6h atrasado (atribuído: @bob) │
│ ├── 🟡 PR #461: 2h restantes (atribuído: @carol) │
│ └── 🟡 PR #463: 3h restantes (atribuído: @alice) │
└─────────────────────────────────────────────────────────────┘
Checklists de Review
Critérios de Review Padronizados
Template Checklist de Code Review:
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST DE REVIEW PR │
├─────────────────────────────────────────────────────────────┤
│ │
│ FUNCIONALIDADE │
│ □ Código faz o que a descrição da tarefa diz │
│ □ Casos edge estão tratados │
│ □ Tratamento de erros é apropriado │
│ □ Sem bugs óbvios │
│ │
│ QUALIDADE DE CÓDIGO │
│ □ Código é legível e auto-documentado │
│ □ Funções/métodos têm tamanho apropriado │
│ □ Sem duplicação de código │
│ □ Segue convenções e padrões do projeto │
│ │
│ TESTING │
│ □ Unit tests cobrem nova funcionalidade │
│ □ Testes são significativos (não só para cobertura) │
│ □ Casos edge estão testados │
│ □ Testes passam local e no CI │
│ │
│ SEGURANÇA │
│ □ Sem dados sensíveis expostos │
│ □ Validação de input em lugar │
│ □ Autenticação/autorização correta │
│ □ Sem vulnerabilidades SQL injection ou XSS │
│ │
│ PERFORMANCE │
│ □ Sem issues óbvios de performance │
│ □ Queries de DB são eficientes (sem N+1) │
│ □ Caching apropriado considerado │
└─────────────────────────────────────────────────────────────┘
Qualidade de Feedback
Categorias de Comentários
Tipos de Feedback Estruturado:
PREFIXOS DE COMENTÁRIO:
┌─────────────────────────────────────────────────────────────┐
│ Prefixo Significado Bloqueia? │
├─────────────────────────────────────────────────────────────┤
│ [BLOCKER] Deve corrigir antes do merge Sim │
│ [ISSUE] Deveria corrigir, importante Sim (geralmente)│
│ [SUGGEST] Considerar mudar Não │
│ [NIT] Menor/preferência estilo Não │
│ [QUESTION] Precisa esclarecimento Depende │
│ [PRAISE] Bom trabalho, bom código Não │
│ [FYI] Compartilhar informação Não │
└─────────────────────────────────────────────────────────────┘
Exemplos:
[BLOCKER] Esta query SQL é vulnerável a injection.
Por favor use queries parametrizadas.
[ISSUE] Esta função tem 200 linhas. Considere dividir
em funções menores para testabilidade.
[SUGGEST] Você poderia simplificar isso com um reduce()
[NIT] Eu preferiria `isActive` sobre `active` para nomes boolean.
[PRAISE] Implementação muito limpa da camada de cache!
Workflows de Aprovação
Aprovações Multi-Estágio
Requisitos de Aprovação:
PR PADRÃO:
┌─────────────────────────────────────────────────────────────┐
│ Requisitos para Merge: │
│ ├── 1+ aprovação do time │
│ ├── Todos blockers resolvidos │
│ ├── Checks de CI passando │
│ └── Sem threads não resolvidas │
└─────────────────────────────────────────────────────────────┘
ÁREAS SENSÍVEIS:
┌─────────────────────────────────────────────────────────────┐
│ Path: /src/auth/*, /src/payments/* │
│ Requisitos: │
│ ├── 2+ aprovações │
│ ├── 1 deve ser do time de segurança │
│ ├── Todos checklists completos │
│ └── CI estendido (scans de segurança) │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Para Autores
- Manter PRs pequenos — <300 linhas ideal, <500 máximo
- Escrever boas descrições — Contexto, o quê, por quê, como
- Auto-revisar primeiro — Pegar issues óbvios
- Responder prontamente — Endereçar feedback rapidamente
- Não levar para o pessoal — Reviews melhoram código, não julgam pessoas
Para Revisores
- Ser pontual — Respeitar o SLA
- Ser específico — Apontar linhas exatas, sugerir fixes
- Ser gentil — Criticar código, não pessoas
- Priorizar feedback — Blockers > Issues > Nits
- Aprender enquanto revisa — É compartilhamento de conhecimento
Para Times
- Definir padrões claros — Documentar como é o bom
- Rotacionar revisores — Espalhar conhecimento
- Rastrear métricas — Melhorar ao longo do tempo
- Celebrar bons reviews — Reforçar qualidade
- Retrospectivas regulares — Refinar o processo