5 min lectura • Guide 675 of 877
Mejorando Calidad de Code Review
Code reviews de alta calidad detectan bugs, comparten conocimiento y mejoran la calidad del código en todo el equipo. GitScrum ayuda a trackear estado de reviews, identificar cuellos de botella de review y mantener visibilidad del proceso como parte del flujo de desarrollo.
Framework de Calidad de Review
Qué Revisar
ÁREAS DE ENFOQUE DE CODE REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ALTA PRIORIDAD (Siempre Revisar): │
│ ✓ Corrección de lógica │
│ ✓ Vulnerabilidades de seguridad │
│ ✓ Manejo de errores │
│ ✓ Casos edge │
│ ✓ Cambios breaking │
│ │
│ PRIORIDAD MEDIA (Usualmente Revisar): │
│ ✓ Implicaciones de performance │
│ ✓ Cobertura de tests │
│ ✓ Diseño de API │
│ ✓ Mantenibilidad del código │
│ ✓ Exactitud de documentación │
│ │
│ BAJA PRIORIDAD (Automatizar Cuando Sea Posible): │
│ ○ Formateo y estilo │
│ ○ Orden de imports │
│ ○ Convenciones de naming │
│ ○ Reglas simples de linting │
│ │
│ AUTOMATIZAR: Usar linters, formatters, type checkers │
│ Reviewers humanos se enfocan en lo que máquinas no pueden │
└─────────────────────────────────────────────────────────────┘
Checklist de Review
CHECKLIST DEL REVIEWER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ANTES DE REVISAR: │
│ ☐ Leer descripción del PR y tarea vinculada │
│ ☐ Entender el contexto y objetivo │
│ ☐ Verificar estado de CI (¿tests pasan?) │
│ │
│ CORRECCIÓN: │
│ ☐ ¿Resuelve el problema declarado? │
│ ☐ ¿Hay errores de lógica? │
│ ☐ ¿Casos edge están manejados? │
│ ☐ ¿Manejo de errores es apropiado? │
│ │
│ SEGURIDAD: │
│ ☐ ¿Validación de input presente? │
│ ☐ ¿No hay datos sensibles expuestos? │
│ ☐ ¿Autenticación/autorización correcta? │
│ ☐ ¿Sin SQL injection, XSS, etc.? │
│ │
│ CALIDAD: │
│ ☐ ¿Código es legible y mantenible? │
│ ☐ ¿Tests son adecuados? │
│ ☐ ¿Sin issues obvios de performance? │
│ ☐ ¿Sigue patrones del equipo? │
└─────────────────────────────────────────────────────────────┘
Feedback Constructivo
Cómo Dar Feedback
FRAMEWORK DE FEEDBACK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESTRUCTURA: │
│ 1. Observación (qué ves) │
│ 2. Impacto (por qué importa) │
│ 3. Sugerencia (qué cambiar) │
│ │
│ EJEMPLO BUENO: │
│ "Veo que este loop procesa todos los items sin límite │
│ (observación). Esto podría causar timeouts con datasets │
│ grandes (impacto). Considera añadir paginación o │
│ procesamiento por lotes (sugerencia)." │
│ │
│ PREFIJOS DE COMENTARIO: │
│ [blocker] - Debe arreglarse antes de merge │
│ [important] - Muy recomendado cambiar │
│ [suggestion] - Mejora opcional │
│ [question] - Pregunta para entender │
│ [nit] - Trivial, tómalo o déjalo │
│ [praise] - Reconocimiento positivo │
│ │
│ BALANCE: │
│ Incluir al menos 1 comentario positivo por review │
│ Reconocer buen trabajo, no solo señalar problemas │
└─────────────────────────────────────────────────────────────┘
Evitar Conflictos
COMUNICACIÓN RESPETUOSA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EN VEZ DE: DECIR: │
│ ───────────────────────────────────────────────── │
│ "Esto está mal" "Creo que hay un bug aquí" │
│ │
│ "¿Por qué hiciste "¿Puedes ayudarme a entender │
│ esto así?" esta decisión?" │
│ │
│ "Siempre haces..." "En este caso específico..." │
│ │
│ "Deberías..." "Considera..." / "¿Qué tal si...?" │
│ │
│ "Obviamente..." "Pienso que..." / "Sugiero..." │
│ │
│ TONO: │
│ • Asumir buena intención │
│ • Ser curioso, no crítico │
│ • Enfocar en código, no en persona │
│ • Preguntar antes de asumir │
│ │
└─────────────────────────────────────────────────────────────┘
Métricas de Review
MÉTRICAS DE CALIDAD DE REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TIEMPO DE TURNAROUND: │
│ Tiempo desde PR abierto hasta primera respuesta │
│ Objetivo: <4 horas laborales │
│ │
│ TIEMPO HASTA MERGE: │
│ Tiempo desde PR abierto hasta merge │
│ Objetivo: <24 horas para PRs normales │
│ │
│ TASA DE DETECCIÓN: │
│ Bugs encontrados en review vs producción │
│ Objetivo: >80% de bugs detectados antes de prod │
│ │
│ DISTRIBUCIÓN DE REVIEW: │
│ % de reviews por cada miembro del equipo │
│ Objetivo: Distribución equilibrada │
│ │
│ TAMAÑO DE PR: │
│ Líneas promedio por PR │
│ Objetivo: <300 líneas │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Revisar el código, no a la persona
- Ser específico y constructivo
- Explicar el "por qué" no solo el "qué"
- Equilibrar crítica con reconocimiento
- Automatizar lo automatizable
- Responder rápido para mantener flujo