Code Review no fluxo ágil
Code review é essencial para qualidade de código e compartilhamento de conhecimento. Mas quando mal gerenciado, vira gargalo que trava a entrega do sprint.
Quanto tempo dedicar ao code review
Regra prática: 15-20% do tempo do sprint em code review.
Em um sprint de 2 semanas com 6 desenvolvedores (~480 horas totais):
- ~72-96 horas em code review
- ~12-16 horas por desenvolvedor
- ~30-45 min por dia por pessoa
Isso deve estar implícito nas estimativas. Se uma feature é 5 pontos, esses 5 já incluem o tempo de review.
Review rápido vs review lento
Review rápido (ideal)
- PR revisado em < 4 horas
- Comentários específicos e acionáveis
- Máximo 2-3 rodadas de revisão
- PR pequeno (< 400 linhas)
Review lento (problema)
- PR sem revisão por 1-2 dias
- Comentários genéricos (“está estranho”, “não gostei”)
- 5+ rodadas de revisão
- PR gigante (1000+ linhas)
Impacto no fluxo do sprint
Um PR travado em review bloqueia:
- O autor (não pode começar próxima tarefa)
- A feature (não chega em produção)
- O sprint (pontos não são entregues)
Regra: PR aberto há mais de 4 horas deve ser escalado no daily.
Boas práticas de review ágil
1. PRs pequenos
“PR ideal: uma feature, uma mudança lógica, < 400 linhas.”
PRs pequenos são revisados mais rápido e com mais qualidade. Se precisa de 1000 linhas, quebre em PRs encadeados.
2. Review primeiro, código depois
Incentive revisores a fazerem code review antes de começar sua tarefa de codificação do dia. Revisão é trabalho desbloqueado — pode ser feito a qualquer momento.
3. Automatize o óbvio
Lint, formatting e testes unitários devem ser automáticos. O revisor deve focar em:
- Arquitetura e design
- Legibilidade
- Edge cases
- Segurança
4. Checklist de review
- A lógica está correta?
- Testes cobrem os cenários principais?
- Não há código desnecessário?
- Nomes de variáveis e funções são claros?
- Não há vulnerabilidades óbvias?
- A mudança segue os padrões do projeto?
5. Aprovação em pares
Mínimo de 1 aprovação para merge. Para código sensível (pagamento, auth), 2 aprovações.
Code Review e estimativas
No Planning Poker, considere:
- Tempo de escrever o código
- Tempo de escrever testes
- Tempo de revisar e iterar no PR
- Tempo de resolver conflitos de merge
Se você não inclui review na estimativa, está sistematicamente subestimando.
Métricas de review
| Métrica | O que indica | Alvo |
|---|---|---|
| Tempo médio de review | Velocidade de feedback | < 4 horas |
| Tamanho médio do PR | Qualidade das mudanças | < 400 linhas |
| Comentários por PR | Qualidade do review | 3-10 |
| Rodadas de revisão | Clareza da mudanças | 1-2 |
| Bugs em produção | Eficácia do review | < 5% |
Conclusão
Code review é investimento em qualidade e conhecimento compartilhado. No fluxo ágil, precisa ser rápido e focado. PRs grandes são o maior inimigo — quebre mudanças em partes pequenas e revisáveis. Cada minuto gasto em review é minuto salvo em bug futuro.