Melhorando Processos de Revisão de Código

Revisão de código é essencial para qualidade mas frequentemente se torna um gargalo. Revisões lentas bloqueiam trabalho, feedback pouco claro causa frustração, e padrões inconsistentes desperdiçam tempo. Melhorar revisão de código requer soluções técnicas, diretrizes claras e mudança cultural.

Problemas de Revisão de Código

Diretrizes de Revisão

O Que Revisar

ÁREAS DE FOCO DA REVISÃO DE CÓDIGO
═══════════════════════════════════

ALTA PRIORIDADE (revisão humana):
─────────────────────────────────────
✓ CORREÇÃO
  ├── Faz o que deveria?
  ├── Casos extremos tratados?
  ├── Tratamento de erro correto?
  └── Falhas de lógica?

✓ DESIGN
  ├── Nível de abstração correto?
  ├── Segue arquitetura?
  ├── Manutenível?
  └── Extensível?

✓ SEGURANÇA
  ├── Vulnerabilidades de injeção?
  ├── Autenticação/autorização?
  ├── Exposição de dados sensíveis?
  └── Validação de entrada?

✓ TESTE
  ├── Testes cobrem mudanças?
  ├── Casos extremos testados?
  ├── Testes legíveis?
  └── Testes manuteníveis?

AUTOMATIZAR (não revisão humana):
─────────────────────────────────────
✗ Formatação
✗ Convenções de estilo
✗ Ordenação de imports
✗ Variáveis não usadas
✗ Erros de tipo
✗ Padrões de bug comuns
└── Tudo tratado por linters/CI

Diretrizes de Tamanho de PR

MELHORES PRÁTICAS DE TAMANHO DE PR
══════════════════════════════════

TAMANHO IDEAL DE PR:
├── < 200 linhas alteradas
├── Mudança lógica única
├── Revisável em 15-30 minutos
└── Um conceito para entender

MUITO GRANDE SE:
├── > 400 linhas alteradas
├── Múltiplas mudanças não relacionadas
├── Leva > 1 hora para revisar
├── Adições de "só mais uma coisa"

COMO MANTER PEQUENO:
─────────────────────────────────────
1. Enviar incrementalmente
   ├── Adicionar esqueleto primeiro
   ├── Adicionar lógica no próximo PR
   └── Adicionar testes em outro

2. Separar refatores
   ├── Refatorar primeiro (PR separado)
   ├── Então adicionar feature
   └── Mais fácil revisar cada um

3. Feature flags
   ├── Enviar incompleto atrás de flag
   ├── Habilitar quando pronto
   └── Sem PRs big-bang

4. PRs empilhados
   ├── PR 1: Fundação
   ├── PR 2: Feature core (depende de 1)
   ├── PR 3: Polimento (depende de 2)
   └── Cada um revisável separadamente

Diretrizes de Feedback

DANDO BOM FEEDBACK
══════════════════

TOM:
─────────────────────────────────────
❌ "Isso está errado"
✓ "Considere usar X porque Y"

❌ "Por que você faria isso?"
✓ "Eu sugeriria abordagem X para manutenibilidade"

❌ "Mude isso" (sem razão)
✓ "Vamos mudar X porque poderia causar problema Y"

CATEGORIZAR COMENTÁRIOS:
─────────────────────────────────────
[Blocker] - Deve corrigir antes do merge
[Sugestão] - Considere, mas opcional
[Nit] - Menor, fica a seu critério
[Pergunta] - Preciso de esclarecimento

EXEMPLOS:
"[Blocker] Este SQL é vulnerável a injeção.
Use query parametrizada: [código exemplo]"

"[Sugestão] Esta função está fazendo muito.
Considere extrair a validação em um
método separado para legibilidade."

"[Nit] Erro de digitação no nome da variável: 'recieve'"

"[Pergunta] Não estou familiarizado com este padrão.
Pode explicar por que escolheu ele?"

ELOGIO:
─────────────────────────────────────
Também inclua feedback positivo:
├── "Bom refactor, muito mais limpo!"
├── "Boa cobertura de teste"
├── "Solução esperta"
└── Balanceie crítica com apreciação

Melhorias de Processo

SLA de Revisão

SLA DE REVISÃO DE CÓDIGO
════════════════════════

TEMPOS ALVO:
├── Primeira revisão: Dentro de 4 horas
├── Revisão de follow-up: Dentro de 2 horas
├── PR simples: Mesmo dia
├── PR complexo: Próximo dia útil

APLIÇÃO:
─────────────────────────────────────
1. Rastrear tempo de revisão no GitScrum
2. Dashboard mostra PRs envelhecendo
3. Lembrete Slack em 4 horas
4. Escalação em 8 horas
5. Relatório em métricas da equipe

FAZENDO FUNCIONAR:
├── Revisão é prioridade maior que trabalho novo
├── Verificar PRs antes de iniciar nova tarefa
├── Bloquear tempo de calendário para revisões
├── Rotacionar quem revisa primeiro
└── Celebrar revisões rápidas

EXCEÇÕES:
├── PRs grandes (24h OK, mas evitar PRs grandes)
├── Domínio complexo (24h OK)
├── Férias/doença (reatribuir revisor)
└── Documentar razão da exceção

Rotação de Revisores

SISTEMA DE ROTAÇÃO DE REVISOR
═════════════════════════════

ABORDAGEM 1: Round Robin
─────────────────────────────────────
Semana 1: Sarah é revisora primária
Semana 2: Mike é revisor primário
Semana 3: Alex é revisor primário
Repetir...

Revisor primário faz primeira passagem em todos PRs

ABORDAGEM 2: Baseada em Expertise
─────────────────────────────────────
Mudanças frontend → Emma ou David
Mudanças backend → Sarah ou Mike
Infraestrutura → Alex ou Jordan
Banco de dados → Sarah ou Alex

Combinar revisor com tipo de mudança

ABORDAGEM 3: Atribuição Automática
─────────────────────────────────────
GitHub CODEOWNERS:
/src/frontend/* @frontend-team
/src/api/* @backend-team
/infrastructure/* @devops-team

Auto-atribui baseado em arquivos alterados

ABORDAGEM 4: Rotação de Pares
─────────────────────────────────────
Cada PR precisa de 1 revisor
Atribuir par rotativo cada semana
Ambos compartilham carga igualmente
Todos revisam ao longo do tempo

Automação

Verificações Automatizadas

AUTOMATIZAR ANTES DA REVISÃO
════════════════════════════

VERIFICAÇÕES DE PIPELINE CI:
─────────────────────────────────────
# .github/workflows/pr.yml
on: [pull_request]

jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      # Formatação
      - run: npm run format:check
      
      # Linting
      - run: npm run lint
      
      # Verificação de tipos
      - run: npm run typecheck
      
      # Testes
      - run: npm run test
      
      # Varredura de segurança
      - run: npm audit
      
      # Verificação de cobertura
      - run: npm run test:coverage

SE ALGUMA FALHAR:
├── PR bloqueado do merge
├── Autor corrige antes da revisão
├── Tempo do revisor não desperdiçado
└── Padrões consistentes

Ferramentas de Revisão

FERRAMENTAS DE REVISÃO DE CÓDIGO
════════════════════════════════

GITSCRUM + GITHUB:
├── PR ligado à tarefa
├── Status sincronizado ao quadro
├── Tempo em revisão rastreado
├── Métricas coletadas

FEATURES DO GITHUB:
├── CODEOWNERS para auto-atribuição
├── Regras de proteção de branch
├── Aprovações requeridas
├── Verificações de status

FERRAMENTAS ADICIONAIS:
├── Danger: Automação de checklist PR
├── SonarQube: Análise de qualidade de código
├── Codacy: Revisão automatizada
└── CodeClimate: Manutenibilidade

SUGESTÕES DE COMENTÁRIOS:
├── Sugestões de revisão assistidas por IA
├── Pegar questões comuns
├── Feedback consistente
└── Acelerar revisor

Melhorias Culturais

Cultura de Revisão de Código

CULTURA DE REVISÃO SAUDÁVEL
═══════════════════════════

PRINCÍPIOS:
─────────────────────────────────────
1. ASSUMIR BOA INTENÇÃO
   "Eles estão tentando o melhor"
   Não: "Por que eles fizeram isso errado?"

2. CRITICAR CÓDIGO, NÃO PESSOAS
   "Este código poderia ser melhorado por..."
   Não: "Você escreveu isso errado"

3. OPORTUNIDADE EDUCACIONAL
   Tanto autor quanto revisor aprendem
   Não: Pegadinhas/pontuação

4. FOCO EM EFICIÊNCIA
   Feedback rápido ajuda todos
   Não: Perfeito às custas de velocidade

ANTI-PATTERNS A EVITAR:
├── Minúcias de estilo (automatize)
├── Revisões ego-driven
├── "Eu teria feito diferente"
├── Requerer perfeição
├── Ignorar PRs
├── Bombardeio de revisão (tudo de uma vez)
└── Comportamento de gate-keeping

PRÁTICAS POSITIVAS:
├── Agradecer autores por bom trabalho
├── Explicar o "porquê" do feedback
├── Oferecer pair se complexo
├── Responder rapidamente
├── Ser aberto à discussão
└── Aprovar quando bom o suficiente

Melhores Práticas

Para Revisão de Código

1. PRs pequenos — Mais fácil revisar bem
2. Revisar rapidamente — Meta de 4 horas
3. Automatizar estilo — Focar humanos na lógica
4. Ser gentil — Criticar código, não pessoas
5. Priorizar revisões — Antes de trabalho novo

Anti-Patterns

ERROS DE REVISÃO DE CÓDIGO:
✗ PRs grandes (> 400 linhas)
✗ Dias para primeira revisão
✗ Verificação manual de estilo
✗ Feedback médio ou pessoal
✗ Requerer perfeição
✗ Sem padrões claros
✗ Gargalo de revisor único
✗ Revisão como reflexão tardia

Soluções Relacionadas

• Reduzindo tempo de resposta de revisão de código
• Identificando gargalos no fluxo de trabalho de desenvolvimento
• Otimização de fluxo de trabalho de desenvolvedor