Otimização de Workflow de Revisão de Código

Revisões de código lentas bloqueiam progresso e frustram desenvolvedores. Revisões rápidas lançam código rapidamente mas podem perder problemas. O objetivo é otimizar para velocidade e qualidade. Este guia cobre abordagens práticas para otimização de revisão de código.

Métricas de Revisão

PRs Pequenos

Tamanho Importa

PULL REQUESTS MENORES
══════════════════════

POR QUE TAMANHO IMPORTA:
─────────────────────────────────────
PRs grandes:
├── Levam mais tempo para revisar
├── Recebem revisões superficiais
├── Mais propensos a bugs
├── Mais difíceis de entender
├── Bloqueiam outro trabalho por mais tempo
├── Revisores adiam
└── Tudo sofre

PRs pequenos:
├── Rápidos para revisar
├── Feedback thorough
├── Fáceis de entender
├── Rápidos para iterar
├── Lançam frequentemente
└── Melhores resultados

DIRETRIZES DE TAMANHO:
─────────────────────────────────────
├── <200 linhas: Fáceis, revisão rápida
├── 200-400 linhas: Razoáveis
├── 400-800 linhas: Ficando grandes
├── >800 linhas: Muito grandes—divida
└── Mire em <400 linhas

COMO DIVIDIR:
─────────────────────────────────────
Funcionalidade grande → Múltiplos PRs:
├── PR 1: Modelos de dados/schema
├── PR 2: API backend
├── PR 3: Componentes frontend
├── PR 4: Integração e testes
├── Cada um é revisável
└── Empilhar ou mesclar sequencialmente

PRs EMPILHADOS:
─────────────────────────────────────
PR 1: Mudança base
  └── PR 2: Depende de PR 1
        └── PR 3: Depende de PR 2

Benefícios:
├── Cada PR é pequeno
├── Pode revisar em paralelo
├── Mesclar em sequência
├── Ferramentas ajudam gerenciar
└── Iteração rápida

Qualidade de PR

Prepare Revisores para Sucesso

MELHORES PRÁTICAS
═════════════════

TÍTULO CLARO:
─────────────────────────────────────
Formato de título bom:
├── [TIPO] Breve descrição
├── [Funcionalidade] Adicionar fluxo de reset de senha
├── [Correção] Resolver problema de timeout de login
├── [Refatorar] Simplificar serviço de usuário
└── Escaneável, descritivo

DESCRIÇÃO BOA:
─────────────────────────────────────
Template:
## O Que
Breve descrição da mudança.

## Por Que
Por que essa mudança é necessária. Link para issue.

## Como
Decisões-chave de implementação. Quaisquer preocupações.

## Teste
Como isso foi testado? Quaisquer passos manuais?

## Screenshots
Se mudanças UI, mostrar antes/depois.

AUTO-REVISÃO PRIMEIRO:
─────────────────────────────────────
Antes de solicitar revisão:
├── Leia seu próprio diff
├── Verifique problemas óbvios
├── Garanta testes passam
├── Verifique formatação
├── Remova código debug
├── Não desperdice tempo do revisor
└── Primeiro revisor é você

CHECKLIST:
─────────────────────────────────────
Checklist PR:
☐ Testes adicionados/atualizados
☐ Documentação atualizada
☐ Sem console.log ou debug
☐ Atende padrões de codificação
☐ Auto-revisado
☐ CI passando

Processo de Revisão

Revisões Eficientes

WORKFLOW DE REVISÃO
═══════════════════

TEMPO DE REVISÃO AGENDADO:
─────────────────────────────────────
Bloqueie tempo para revisões:
├── Manhã: 30 min tempo de revisão
├── Após almoço: 30 min tempo de revisão
├── Hábito consistente
├── Não deixe PRs se acumularem
├── Parte do trabalho diário
└── Prioridade junto com codificação

PRIORIZAÇÃO DE REVISÃO:
─────────────────────────────────────
Ordem para revisar:
├── 1. PRs bloqueantes (outros esperando)
├── 2. PRs pequenos (vitórias rápidas)
├── 3. PRs mais velhos (prevenir stale)
├── 4. PRs grandes (foco profundo)
└── Limpe a fila eficientemente

NO QUE FOCAR:
─────────────────────────────────────
Valor alto:
├── Correção (funciona?)
├── Design (manutenível?)
├── Casos extremos (o que quebra?)
├── Segurança (vulnerabilidades?)
├── Arquitetura (encaixa no sistema?)
└── Áreas de julgamento humano

Deixe para automação:
├── Formatação (Prettier, etc.)
├── Linting (ESLint, etc.)
├── Verificação de tipo (TypeScript)
├── Cobertura de teste (CI)
├── Varredura de segurança (CI)
└── Máquinas são mais rápidas

QUALIDADE DE FEEDBACK:
─────────────────────────────────────
Feedback bom:
├── Específico (não vago)
├── Acionável (o que fazer)
├── Gentil (respeitoso)
├── Severidade clara (bloqueante vs nit)
└── Construtivo

Prefixos:
├── [bloqueante] Deve corrigir antes de mesclar
├── [sugestão] Considere essa abordagem
├── [pergunta] Ajude-me a entender
├── [nit] Coisa menor, opcional
└── Expectativas claras

Automação

Deixe Máquinas Ajudarem

VERIFICAÇÕES AUTOMATIZADAS
══════════════════════════

ANTES DE REVISÃO HUMANA:
─────────────────────────────────────
CI executa:
├── Build passa
├── Testes passam
├── Linting passa
├── Verificação de tipo passa
├── Threshold de cobertura atendido
├── Varredura de segurança limpa
├── Tudo verde antes de revisão
└── Não revise PRs falhando

ATRIBUIÇÃO AUTOMATIZADA:
─────────────────────────────────────
Proprietários de código:
├── Arquivo CODEOWNERS
├── Auto-atribua revisores
├── Revisores certos especialistas
├── Sem atribuição manual
└── Roteamento mais rápido

Regras de auto-atribuição:
├── Round-robin equipe
├── Balanceamento de carga
├── Correspondência de expertise
├── Distribuição justa
└── Ninguém sobrecarregado

FORMATAÇÃO AUTOMÁTICA:
─────────────────────────────────────
Ao salvar ou commit:
├── Prettier formata código
├── ESLint corrige problemas
├── Sem debates de formatação
├── Base de código consistente
├── Revisão foca na lógica
└── Tempo salvo

VERIFICAÇÕES DE STATUS:
─────────────────────────────────────
Verificações requeridas:
├── ci/build: ✓ Passou
├── ci/test: ✓ Passou
├── ci/lint: ✓ Passou
├── security/scan: ✓ Passou
├── coverage: ✓ 87% (≥80%)
└── Todas devem passar para mesclar

Acordos de Equipe

Padrões de Revisão

ACORDOS DE REVISÃO DE EQUIPE
════════════════════════════

SLA DE TEMPO DE RESPOSTA:
─────────────────────────────────────
Acordo de equipe:
├── Primeira resposta: <4 horas
├── Revisão completa: <24 horas
├── PRs urgentes: <2 horas
├── Expectativas explícitas
├── Rastreado e medido
└── Todos se comprometem

REQUISITOS DE APROVAÇÃO:
─────────────────────────────────────
Defina claramente:
├── Quantas aprovações? (1-2)
├── Quem pode aprovar?
├── Proprietário de código requerido?
├── Quando substituir?
├── Processo de emergência?
└── Diretrizes escritas

NORMAS DE FEEDBACK:
─────────────────────────────────────
Como damos feedback:
├── Seja gentil e respeitoso
├── Faça perguntas, não assuma
├── Explique o "porquê"
├── Use prefixos para severidade
├── Elogie código bom também
├── Assuma boa intenção
└── Cultura de equipe

QUANDO MESCLAR:
─────────────────────────────────────
Mesclar quando:
├── Aprovações requeridas recebidas
├── Todas verificações passando
├── Todos comentários bloqueantes resolvidos
├── Sem conversas não resolvidas
└── Critérios claros

Integração GitScrum

Rastreamento de Revisão

GITSCRUM PARA REVISÃO DE CÓDIGO
═══════════════════════════════

STATUS DE TAREFA:
─────────────────────────────────────
Colunas de workflow:
├── Em Andamento → PR aberto
├── Em Revisão → Aguardando revisão
├── Feito → PR mesclado
├── Transições automáticas
└── Visibilidade de status

VISIBILIDADE DE PR:
─────────────────────────────────────
Na tarefa:
├── Link PR visível
├── Status PR (aberto, mesclado)
├── Status de revisão
├── Status de verificações
├── Contexto de relance
└── Visão integrada

MÉTRICAS:
─────────────────────────────────────
Rastreie saúde de revisão:
├── Tempo médio de revisão
├── Conformidade SLA de revisão
├── Distribuição de tamanho PR
├── Tempo de tarefa bloqueada
├── Dados para melhoria
└── Meça e melhore

Melhores Práticas

Para Otimização de Revisão de Código

1. PRs pequenos — <400 linhas
2. Resposta rápida — <4 horas primeiro olhar
3. Verificações automatizadas — Máquinas primeiro
4. Padrões claros — Acordos escritos
5. Foco no valor — Design sobre formatação

Anti-Padrões

ERROS DE REVISÃO DE CÓDIGO:
✗ PRs grandes (>1000 linhas)
✗ Revisões levando dias
✗ Revisando CI falhando
✗ Debates de formatação
✗ Sem expectativas de tempo de resposta
✗ Uma pessoa gargalo
✗ Aprovações de carimbo de borracha
✗ Feedback duro ou pessoal

Soluções Relacionadas

• Simplificando processos de revisão de código
• Melhorando tempos de resposta de revisão de código
• Como melhorar tempo de ciclo de revisão de código