4 min lectura • Guide 250 of 877
Optimizando Procesos de Code Review
Code review es esencial para la calidad pero a menudo se convierte en un cuello de botella. Los reviews se acumulan, el feedback es lento, y los developers hacen context-switch entre codear y revisar. Optimizar code review significa turnaround más rápido, mejor feedback, y reviews que detectan issues reales en lugar de bikeshedding.
Problemas de Review
| Problema | Causa | Solución |
|---|---|---|
| Reviews toman días | PRs grandes, sin SLA | Límites de tamaño, SLA |
| Bikeshedding | Sin guidelines de foco | Checklist de review |
| Feedback inconsistente | Sin estándares | Style guide |
| Cuello de botella en seniors | Solo seniors revisan | Entrenar a todos |
| Context switching | Requests de review aleatorios | Tiempo de review en batch |
Reviews Más Rápidos
PRs Más Pequeños
CULTURA DE PR PEQUEÑO
═════════════════════
POR QUÉ IMPORTA EL TAMAÑO:
─────────────────────────────────────
PR Líneas Tiempo Review Detección Bugs
────────────────────────────────────────────
< 100 15 min Alta
100-400 30 min Buena
400-800 60 min Media
800+ Skim/skim Baja
MÁS DE 400 LÍNEAS = DIVIDIR EL PR
CÓMO DIVIDIR:
─────────────────────────────────────
Feature work:
├── PR 1: Backend API
├── PR 2: Frontend component
├── PR 3: Integration + tests
└── Cada uno revisable independientemente
Refactoring:
├── PR 1: Extraer función
├── PR 2: Usar nueva función
├── PR 3: Remover código viejo
└── Cada paso bajo riesgo
SLA de Review
SLA DE CODE REVIEW
══════════════════
TIEMPOS TARGET:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PR Pequeño (<100 líneas): 4 horas │
│ PR Normal (100-400 líneas): 24 horas │
│ PR Grande (>400): Dividirlo │
│ Hotfix/Urgente: 2 horas │
│ │
└─────────────────────────────────────────────────────────────┘
CÓMO CUMPLIR SLA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ • Tiempo dedicado de review (ej: 10-11am) │
│ • Rotación de revisores │
│ • Notificaciones/alertas │
│ • Trackear métricas de review time │
│ │
└─────────────────────────────────────────────────────────────┘
Qué Revisar
FOCO DEL CODE REVIEW
════════════════════
✅ REVISAR ESTO (Humano):
┌─────────────────────────────────────────────────────────────┐
│ │
│ • ¿La lógica es correcta? │
│ • ¿Hay problemas de seguridad? │
│ • ¿Es mantenible y legible? │
│ • ¿Los tests cubren casos importantes? │
│ • ¿Se alinea con la arquitectura? │
│ • ¿Hay edge cases no manejados? │
│ │
└─────────────────────────────────────────────────────────────┘
❌ NO REVISAR ESTO (Automatizar):
┌─────────────────────────────────────────────────────────────┐
│ │
│ • Formateo → Prettier/Black │
│ • Linting → ESLint/Pylint │
│ • Type checking → TypeScript/MyPy │
│ • Cobertura → CI/CD pipeline │
│ • Vulnerabilidades → Dependabot/Snyk │
│ │
└─────────────────────────────────────────────────────────────┘
TIPOS DE COMENTARIOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 🔴 BLOCKER: "Esto DEBE cambiarse antes de merge" │
│ 🟡 SUGERENCIA: "Considera esto, pero no es blocker" │
│ 💬 PREGUNTA: "¿Por qué esta approach?" │
│ 👍 POSITIVO: "Bien manejado" │
│ │
└─────────────────────────────────────────────────────────────┘
En GitScrum
CODE REVIEW EN GITSCRUM
═══════════════════════
TRACKING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ • Column "In Review" en board │
│ • Link PRs a tareas │
│ • Métricas de cycle time │
│ • Alertas por PRs esperando │
│ │
└─────────────────────────────────────────────────────────────┘