Revisión de Código Efectiva | Guía GitScrum
Establece procesos de code review que mejoren calidad y difundan conocimiento. Integración con GitHub, GitLab y Bitbucket para PRs fluidos.
10 min de lectura
La revisión de código es más que encontrar bugs—es una puerta de calidad, mecanismo de compartir conocimiento, y herramienta de alineación de equipo. Procesos de revisión efectivos balancean minuciosidad con velocidad, asegurando altos estándares sin convertirse en cuello de botella. Las integraciones Git de GitScrum conectan revisiones a tu flujo de proyecto, manteniendo visibilidad y responsabilidad a través del proceso de desarrollo.
Fundamentos de Revisión de Código
Propósito de la Revisión
POR QUÉ REVISAMOS CÓDIGO:
┌─────────────────────────────────────────────────────────────┐
│ OBJETIVOS MÁS ALLÁ DE ENCONTRAR BUGS │
├─────────────────────────────────────────────────────────────┤
│ │
│ OBJETIVOS PRIMARIOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🐛 DETECCIÓN DE DEFECTOS ││
│ │ Atrapar bugs antes que lleguen a producción ││
│ │ Errores lógica, casos borde, problemas seguridad ││
│ │ ││
│ │ 📚 COMPARTIR CONOCIMIENTO ││
│ │ Difundir entendimiento a través del equipo ││
│ │ Reducir silos conocimiento, factor bus ││
│ │ ││
│ │ 📏 APLICACIÓN DE ESTÁNDARES ││
│ │ Mantener patrones código consistentes ││
│ │ Alineación arquitectura, consistencia estilo ││
│ │ ││
│ │ 🎓 MENTORÍA ││
│ │ Enseñar y aprender a través del diálogo revisión ││
│ │ Desarrollo junior, supervisión senior ││
│ │ ││
│ │ 🤝 PROPIEDAD COLECTIVA ││
│ │ Múltiples personas entienden cada cambio ││
│ │ Mejor mantenimiento, debugging más rápido ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Integrando con GitScrum
Visibilidad de PR
INTEGRACIÓN GIT GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ CONECTANDO PULL REQUESTS A TAREAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ENLACE AUTOMÁTICO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Cuando desarrolladores incluyen ID tarea en branch/PR: ││
│ │ ││
│ │ Nombrado branch: ││
│ │ feature/PROJ-123-autenticacion-usuario ││
│ │ ││
│ │ Título PR: ││
│ │ PROJ-123: Agregar flujo autenticación usuario ││
│ │ ││
│ │ GitScrum automáticamente: ││
│ │ ├── Enlaza PR a tarea PROJ-123 ││
│ │ ├── Muestra estado PR en tarjeta tarea ││
│ │ ├── Actualiza feed actividad ││
│ │ └── Notifica asignados de eventos PR ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ VISIBILIDAD TABLERO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Columna Code Review muestra estado PR: ││
│ │ ││
│ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ ││
│ │ │ PROJ-123 │ │ PROJ-456 │ │ PROJ-789 │ ││
│ │ │ Auth flow │ │ Dashboard │ │ Reportes │ ││
│ │ │ │ │ │ │ │ ││
│ │ │ 🟢 PR #456 │ │ 🟡 PR #461 │ │ 🔴 PR #458 │ ││
│ │ │ Aprobado │ │ Revisando │ │ Cambios │ ││
│ │ └───────────┘ └───────────┘ └───────────┘ ││
│ │ ││
│ │ Filtros: [Todos PRs] [Necesita Revisión] [Aprobado] ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Flujo de Revisión
INTEGRACIÓN PROCESO REVISIÓN:
┌─────────────────────────────────────────────────────────────┐
│ FLUJO REVISIÓN DE PRINCIPIO A FIN │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. TAREA INICIADA → EN PROGRESO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Desarrollador: ││
│ │ • Mueve tarea a "En Progreso" ││
│ │ • Crea branch con ID tarea ││
│ │ • Desarrolla y prueba localmente ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 2. PR CREADO → EN REVISIÓN │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Desarrollador: ││
│ │ • Abre PR con ID tarea en título ││
│ │ • GitScrum auto-mueve tarea a "Code Review" ││
│ │ • Solicita revisores ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 3. CICLO REVISIÓN │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Revisores: ││
│ │ • Revisan código en GitHub/GitLab ││
│ │ • Dejan comentarios, aprueban, o solicitan cambios ││
│ │ ││
│ │ Tarea refleja: ││
│ │ • Estado revisión (pendiente/aprobado/cambios) ││
│ │ • Estado CI (pasando/fallando) ││
│ │ • Conteo comentarios ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 4. APROBADO → LISTO PARA MERGE │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Todos revisores aprobaron: ││
│ │ • Estado PR muestra "Aprobado" ││
│ │ • Desarrollador o tech lead hace merge ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 5. MERGED → HECHO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Al merge: ││
│ │ • GitScrum puede auto-mover tarea a "Hecho" ││
│ │ • O mover a "Deployed" para rastreo deploy ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Guías de Revisión
Para Autores
ENVIANDO CÓDIGO PARA REVISIÓN:
┌─────────────────────────────────────────────────────────────┐
│ PREPARANDO REVISORES PARA ÉXITO │
├─────────────────────────────────────────────────────────────┤
│ │
│ ANTES DE SOLICITAR REVISIÓN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ □ Auto-revisar cambios primero ││
│ │ □ Ejecutar todos tests localmente (deben pasar) ││
│ │ □ Verificar linting/formateo pasa ││
│ │ □ Remover código debug, console.log, TODOs ││
│ │ □ Verificar PR tamaño razonable (<400 líneas) ││
│ │ □ Agregar tests para nueva funcionalidad ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRs PEQUEÑOS, ENFOCADOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Tamaño PR │ Tiempo Revisión │ Calidad ││
│ │────────────────┼─────────────────┼──────────────────────││
│ │ < 100 líneas │ 15-30 min │ Minuciosa ││
│ │ 100-400 líneas │ 30-60 min │ Buena ││
│ │ 400-800 líneas │ 60-90 min │ Declinando ││
│ │ > 800 líneas │ Frecuentemente │ Pobre (¡dividir PR!) ││
│ │ │ hojeado │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RESPONDIENDO A FEEDBACK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✓ Responder a cada comentario ││
│ │ ✓ Pedir aclaración si no claro ││
│ │ ✓ Explicar razonamiento si no estás de acuerdo ││
│ │ ✓ Push fixes como nuevos commits (trazabilidad) ││
│ │ ✓ Re-solicitar revisión cuando listo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Para Revisores
DANDO REVISIONES EFECTIVAS:
┌─────────────────────────────────────────────────────────────┐
│ MEJORES PRÁCTICAS REVISIÓN │
├─────────────────────────────────────────────────────────────┤
│ │
│ MENTALIDAD REVISIÓN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✓ Revisar código, no la persona ││
│ │ ✓ Asumir intención positiva ││
│ │ ✓ Considerar múltiples enfoques válidos ││
│ │ ✓ Ser explícito sobre severidad (bloqueante vs sugerencia│
│ │ ✓ Ofrecer alternativas, no solo crítica ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TIPOS COMENTARIO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BLOQUEANTE (Debe arreglar): ││
│ │ "🔴 BLOQUEANTE: Este SQL es vulnerable a inyección. ││
│ │ Usar queries parametrizadas en su lugar." ││
│ │ ││
│ │ SUGERENCIA (Debería considerar): ││
│ │ "💡 SUGERENCIA: Considera usar async/await aquí ││
│ │ para mejor legibilidad. No bloqueante pero mejoraría." ││
│ │ ││
│ │ PREGUNTA (Necesita aclaración): ││
│ │ "❓ PREGUNTA: ¿Por qué cacheamos esto por 24 horas? ││
│ │ ¿Hay un requerimiento específico?" ││
│ │ ││
│ │ NIT (Menor, opcional): ││
│ │ "📝 NIT: Typo en nombre variable 'recieve' → 'receive'" ││
│ │ ││
│ │ ELOGIO (Feedback positivo): ││
│ │ "👍 ¡Buen enfoque! Esto maneja los casos borde ││
│ │ elegantemente." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EXPECTATIVAS TIEMPO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Solicitudes revisión deben manejarse dentro de: ││
│ │ ││
│ │ Primera respuesta: < 4 horas durante horario trabajo ││
│ │ Revisión completa: < 1 día laboral ││
│ │ Re-revisión: < 4 horas (cambios menores) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Automatización
Integración CI
VERIFICACIONES AUTOMATIZADAS ANTES DE REVISIÓN:
┌─────────────────────────────────────────────────────────────┐
│ DEJAR QUE MÁQUINAS VERIFIQUEN LO QUE HACEN MEJOR │
├─────────────────────────────────────────────────────────────┤
│ │
│ AUTOMATIZACIÓN PRE-REVISIÓN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Pipeline CI (debe pasar antes de revisión): ││
│ │ ││
│ │ □ Build compila exitosamente ││
│ │ □ Todos tests pasan ││
│ │ □ Cobertura código sobre umbral ││
│ │ □ Linting pasa (sin problemas estilo) ││
│ │ □ Formateo correcto (Prettier, Black, etc.) ││
│ │ □ Escaneo seguridad pasa ││
│ │ □ Verificación tipos pasa (TypeScript, mypy) ││
│ │ ││
│ │ Si CI falla → Autor debe arreglar antes de solicitar ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ VISIBILIDAD GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Tarea muestra estado CI: ││
│ │ ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ PROJ-123: Autenticación Usuario │ ││
│ │ │ │ ││
│ │ │ PR #456 Estado CI: │ ││
│ │ │ ✓ Build Pasó │ ││
│ │ │ ✓ Tests 142/142 pasaron │ ││
│ │ │ ✓ Linting Sin problemas │ ││
│ │ │ ✓ Cobertura 87% (≥80% requerido) │ ││
│ │ │ ✓ Seguridad Sin vulnerabilidades │ ││
│ │ │ │ ││
│ │ │ Listo para revisión ✓ │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Anti-Patrones Comunes
Qué Evitar
ANTI-PATRONES REVISIÓN CÓDIGO:
┌─────────────────────────────────────────────────────────────┐
│ PRÁCTICAS QUE DAÑAN EFECTIVIDAD REVISIÓN │
├─────────────────────────────────────────────────────────────┤
│ │
│ ✗ RUBBER STAMPING │
│ Problema: Aprobar sin leer │
│ Señal: Aprobaciones rápidas, sin comentarios, bugs prod │
│ Arreglo: Requerir tiempo mínimo, rastrear tasa comentarios│
│ │
│ ✗ GATEKEEPING │
│ Problema: Usar revisión para bloquear por estilo personal │
│ Señal: Misma persona bloquea todo, basado en opinión │
│ Arreglo: Estándares claros, ruta escalación, rotar │
│ │
│ ✗ REVISIÓN SIN FIN │
│ Problema: Nuevos comentarios después de cada ronda │
│ Señal: 5+ rondas revisión, metas moviéndose │
│ Arreglo: Todo feedback primera ronda, delimitar tiempo │
│ │
│ ✗ DISEÑO EN REVISIÓN CÓDIGO │
│ Problema: Cuestionar arquitectura después código escrito │
│ Señal: "¿Por qué lo hacemos así?" en PR │
│ Arreglo: Revisiones diseño antes coding, RFCs cambios │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
Hacer
PRÁCTICAS REVISIÓN CÓDIGO EFECTIVAS:
✓ AUTOMATIZAR VERIFICACIONES ESTILO
Dejar linters manejar formateo, enfocarse en lógica
✓ MANTENER PRs PEQUEÑOS
<400 líneas habilita revisión minuciosa
✓ RESPONDER RÁPIDAMENTE
<4 horas primera respuesta mantiene flujo
✓ SER ESPECÍFICO EN FEEDBACK
Mostrar alternativa, no solo problema
✓ ETIQUETAR SEVERIDAD COMENTARIO
Bloqueante vs sugerencia vs nit
No Hacer
TRAMPAS REVISIÓN CÓDIGO:
✗ REVISAR PRs GIGANTES
>800 líneas será hojeado, no revisado
✗ DEBATES ESTILO EN REVISIONES
Automatizar con formatters, o documentar estándares
✗ APROBAR SIN LEER
Derrota propósito completamente
✗ SER DURO
Revisión código es para código, no persona