5 min lectura • Guide 81 of 877
Conduciendo Code Reviews Efectivos
Los code reviews pueden ser un cuello de botella o un multiplicador de fuerza. Reviews efectivos mejoran la calidad del código, dispersan conocimiento y detectan bugs temprano. Reviews pobres crean fricción, retrasan trabajo y dañan la moral del equipo. GitScrum se integra con GitHub/GitLab para hacer los reviews visibles y eficientes.
Objetivos del Code Review
| Objetivo | Cómo Lograr |
|---|---|
| Encontrar bugs | Enfocarse en lógica, edge cases |
| Dispersar conocimiento | Revisar entre especialidades |
| Mejorar diseño | Discutir arquitectura |
| Mantener estándares | Estilo, patrones consistentes |
| Mentorear | Explicar razonamiento |
Proceso de Review
Mejores Prácticas de Envío
CHECKLIST DEL AUTOR DE PR
═════════════════════════
ANTES DE ENVIAR:
- [ ] Auto-revisé el diff
- [ ] Tests pasan localmente
- [ ] Linter pasa
- [ ] Sin código de debug
- [ ] Descripción explica por qué
BUENA DESCRIPCIÓN DE PR:
─────────────────────────────────────
## Qué
Descripción breve del cambio.
## Por qué
Contexto y motivación.
## Cómo
Enfoque técnico tomado.
## Testing
Cómo fue verificado.
## Screenshots (si UI)
Antes/después si aplica.
## Relacionado
Links a tarea de GitScrum, docs, etc.
─────────────────────────────────────
Guías de Tamaño de PR
RECOMENDACIONES DE TAMAÑO DE PR
═══════════════════════════════
IDEAL: 50-200 líneas cambiadas
ACEPTABLE: 200-400 líneas cambiadas
MUY GRANDE: 400+ líneas cambiadas
POR QUÉ PRs PEQUEÑOS:
├── Más fácil revisar rigurosamente
├── Turnaround más rápido
├── Menos riesgo por cambio
├── Más simple de revertir
└── Mejor transferencia de conocimiento
ESTRATEGIAS DE DIVISIÓN:
├── Feature flags para trabajo parcial
├── Extraer refactoring separadamente
├── Separar tests de implementación
├── Infraestructura vs lógica
└── Backend vs frontend
Proceso del Revisor
FLUJO DE TRABAJO DE REVIEW
══════════════════════════
FASE 1: ENTENDER (5 min)
├── Leer descripción del PR
├── Verificar contexto de tarea vinculada
├── Entender el objetivo
└── Revisar plan de testing
FASE 2: ALTO NIVEL (10 min)
├── ¿Es correcto el enfoque?
├── ¿Preocupaciones de arquitectura?
├── ¿Componentes faltantes?
└── ¿Alcance correcto?
FASE 3: DETALLADO (15-30 min)
├── Correctitud de lógica
├── Edge cases manejados
├── Manejo de errores
├── Implicaciones de performance
├── Consideraciones de seguridad
└── Cobertura de tests
FASE 4: RESPONDER (5 min)
├── Organizar feedback
├── Priorizar comentarios
├── Aprobar, solicitar cambios, o comentar
└── Ser responsivo a preguntas
Framework de Feedback
Tipos de Comentarios
TIPOS DE COMENTARIOS DE REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ [BLOQUEADOR] - Debe arreglarse antes de merge │
│ • Issues de seguridad │
│ • Bugs en lógica │
│ • Tests faltantes para rutas críticas │
│ │
│ [SUGERENCIA] - Mejora recomendada │
│ • Mejor enfoque posible │
│ • Mejoras de legibilidad │
│ • Oportunidades de refactoring │
│ │
│ [NIT] - Menor, no bloquea │
│ • Preferencias de estilo │
│ • Sugerencias menores de nombrado │
│ • Comentarios opcionales │
│ │
│ [PREGUNTA] - Necesita entendimiento │
│ • "¿Qué pasa si...?" │
│ • "¿Por qué este enfoque?" │
│ • "¿Consideraste...?" │
│ │
│ [ELOGIO] - Reconocer buen trabajo │
│ • "¡Buen manejo de este edge case!" │
│ • "¡Código muy limpio!" │
│ │
└─────────────────────────────────────────────────────────────┘
Dando Feedback Constructivo
FEEDBACK CONSTRUCTIVO:
┌───────────────────────────────────────────────────────────┐
│ │
│ EN VEZ DE: INTENTA: │
│ ───────────────────────────────────────────────────────── │
│ "Esto está mal" "Esto podría causar X. │
│ ¿Qué tal Y en su lugar?" │
│ │
│ "Mal nombre" "¿Qué tal `userCount` │
│ para más claridad?" │
│ │
│ "¿Por qué hiciste esto?" "Tengo curiosidad sobre el │
│ razonamiento aquí." │
│ │
│ "Usa X" "X podría funcionar mejor │
│ aquí porque..." │
│ │
│ PRINCIPIOS: │
│ • Hacer preguntas en lugar de demandar │
│ • Explicar por qué, no solo qué │
│ • Ofrecer alternativas, no solo críticas │
│ • Asumir buena intención │
│ • Revisar código, no personas │
│ │
└───────────────────────────────────────────────────────────┘
Integración con GitScrum
Vinculación PR-Tarea
VINCULACIÓN PR A TAREA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FLUJO AUTOMATIZADO: │
│ │
│ PR Creado → Tarea se mueve a "En Revisión" │
│ PR Aprobado → Tarea se mueve a "Aprobado" │
│ PR Merged → Tarea se mueve a "Hecho" │
│ │
│ VISTA EN GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Tarea: AUTH-123 Implementar login OAuth ││
│ │ ││
│ │ PR Vinculado: #456 - feat: add oauth login ││
│ │ Estado PR: ✅ Aprobado (2 aprobaciones) ││
│ │ Checks CI: ✅ Pasando ││
│ │ Tiempo en review: 4 horas ││
│ │ ││
│ │ [Ver PR] [Mergear] ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘