Procesos de Code Review | Guía GitScrum
Haz code reviews más rápidos, valiosos y menos conflictivos. Guías claras, automatización y mejoras culturales para tu equipo.
5 min de lectura
Code review es esencial para la calidad pero frecuentemente se convierte en cuello de botella. Reviews lentos bloquean trabajo, feedback poco claro causa frustración y estándares inconsistentes desperdician tiempo. Mejorar code review requiere soluciones técnicas, guías claras y cambio cultural.
Problemas de Code Review
| Problema | Solución |
|---|---|
| Reviews toman días | SLA de review + PRs más pequeños |
| Feedback nitpicky | Automatizar checks de estilo |
| Estándares poco claros | Guías escritas |
| Reviews conflictivos | Código de conducta |
| Cuello de botella de reviewer | Más reviewers + rotación |
Guías de Review
Qué Revisar
ÁREAS DE ENFOQUE DE CODE REVIEW
═══════════════════════════════
ALTA PRIORIDAD (review humano):
─────────────────────────────────────
✓ CORRECCIÓN
├── ¿Hace lo que debería?
├── ¿Casos edge manejados?
├── ¿Manejo de errores correcto?
└── ¿Fallos de lógica?
✓ DISEÑO
├── ¿Nivel de abstracción correcto?
├── ¿Sigue arquitectura?
├── ¿Mantenible?
└── ¿Extensible?
✓ SEGURIDAD
├── ¿Vulnerabilidades de inyección?
├── ¿Autenticación/autorización?
├── ¿Exposición de datos sensibles?
└── ¿Validación de input?
✓ TESTING
├── ¿Tests cubren cambios?
├── ¿Casos edge testeados?
├── ¿Tests legibles?
└── ¿Tests mantenibles?
AUTOMATIZAR (no review humano):
─────────────────────────────────────
✗ Formateo
✗ Convenciones de estilo
✗ Orden de imports
✗ Variables no usadas
✗ Errores de tipos
✗ Patrones de bugs comunes
└── Todo manejado por linters/CI
Guías de Tamaño de PR
MEJORES PRÁCTICAS DE TAMAÑO DE PR
═════════════════════════════════
TAMAÑOS DE PR:
─────────────────────────────────────
Pequeño (<200 líneas): ████████████ Ideal
Mediano (200-400): ████████ OK
Grande (400-800): ████ Evitar
Muy grande (>800): ██ Nunca
─────────────────────────────────────
POR QUÉ PEQUEÑOS PRs:
├── Reviews más rápidos (menos a leer)
├── Reviews más profundos (más enfocados)
├── Menos conflictos de merge
├── Más fácil de revertir si hay problemas
└── Flujo más suave
TÉCNICAS PARA PRs PEQUEÑOS:
├── Un feature = un PR
├── Separar refactoring de features
├── Commits atómicos
├── Feature flags para trabajo en progreso
└── Descomponer historias grandes
Velocidad de Review
SLA de Review
POLÍTICA DE SLA DE REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ OBJETIVO: Primera respuesta en 4 horas laborales │
│ │
│ PRIORIDADES: │
│ 1. Hotfixes: Inmediato │
│ 2. Desbloqueadores: 2 horas │
│ 3. Normal: 4 horas │
│ 4. Bajo prioridad: 1 día │
│ │
│ IMPLEMENTACIÓN: │
│ ├── Notificación de nuevos PRs │
│ ├── Rotación de reviewer de turno │
│ ├── Bloques de tiempo dedicados a review │
│ └── Métricas de tiempo de respuesta │
│ │
│ REGLA: Review antes que nuevo código │
│ Si hay PRs esperando, revisa primero │
│ │
└─────────────────────────────────────────────────────────────┘
Rotación de Reviewers
SISTEMA DE ROTACIÓN DE REVIEWERS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MODELO DE ROTACIÓN: │
│ ├── Reviewer primario rota diariamente │
│ ├── Reviewer primario tiene primera opción │
│ ├── Cualquiera puede revisar si primario ocupado │
│ └── Cross-training: variar quién revisa qué │
│ │
│ BENEFICIOS: │
│ ├── Distribuir carga de review │
│ ├── Compartir conocimiento │
│ ├── Evitar dependencia de un reviewer │
│ └── Tiempo de review más consistente │
│ │
│ SEMANA EJEMPLO: │
│ Lunes: Ana (primario), resto como backup │
│ Martes: Carlos (primario) │
│ Miércoles: David (primario) │
│ Jueves: Elena (primario) │
│ Viernes: Fernando (primario) │
│ │
└─────────────────────────────────────────────────────────────┘
Calidad del Feedback
Cómo Dar Buen Feedback
EJEMPLOS DE FEEDBACK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✗ MAL: "Este código es feo" │
│ ✓ BIEN: "Considera extraer este bloque a una función │
│ separada para mejorar legibilidad" │
│ │
│ ✗ MAL: "Esto no funciona" │
│ ✓ BIEN: "Este código fallará cuando userId es null. │
│ Sugiero añadir validación: if (!userId) return;" │
│ │
│ ✗ MAL: "¿Por qué hiciste esto?" │
│ ✓ BIEN: "Tengo curiosidad sobre esta decisión. ¿Podrías │
│ explicar el razonamiento?" │
│ │
│ TIPOS DE COMENTARIOS: │
│ • [blocker]: Debe arreglarse antes de merge │
│ • [suggestion]: Mejora opcional │
│ • [question]: Necesito entender │
│ • [nit]: Trivial, ignora si quieres │
│ • [praise]: ¡Buen trabajo en esto! │
│ │
└─────────────────────────────────────────────────────────────┘
Automatización
AUTOMATIZAR PARA LIBERAR REVIEWERS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AUTOMATIZAR: │
│ ├── Formateo (Prettier, Black, gofmt) │
│ ├── Linting (ESLint, Pylint) │
│ ├── Type checking (TypeScript, mypy) │
│ ├── Tests (unit, integration) │
│ ├── Cobertura de código │
│ ├── Análisis de seguridad (SAST) │
│ └── Análisis de dependencias │
│ │
│ REGLA: No merge si CI falla │
│ │
│ BENEFICIO: │
│ Reviewers humanos se enfocan en: │
│ • Lógica de negocio │
│ • Decisiones de diseño │
│ • Mantenibilidad │
│ • Conocimiento compartido │
│ │
└─────────────────────────────────────────────────────────────┘