6 min lectura • Guide 436 of 877
Guías de Code Review
Los code reviews detectan bugs, comparten conocimiento y mejoran la calidad de código. Buenas revisiones son colaborativas y educativas. Malas revisiones son lentas, puntillosas o aprobaciones sin revisar. Esta guía cubre prácticas efectivas de code review.
Áreas de Enfoque del Review
| Área | Prioridad |
|---|---|
| Correctitud | Alta - ¿Funciona? |
| Diseño | Alta - ¿Es mantenible? |
| Edge cases | Media - ¿Qué puede fallar? |
| Estilo | Baja - Deja que linters manejen |
Proceso de Review
Enviando Reviews
PROCESO DE CODE REVIEW
══════════════════════
ANTES DE ENVIAR PR:
─────────────────────────────────────
El autor debe:
├── Auto-revisar primero
├── Ejecutar tests localmente
├── Verificar que linting pasa
├── Escribir descripción clara
├── Vincular a issue/ticket
├── Mantener PR pequeño (< 400 líneas ideal)
└── PR preparado
DESCRIPCIÓN DEL PR:
─────────────────────────────────────
Incluir:
├── Qué: Resumen de cambios
├── Por qué: Contexto y motivación
├── Cómo: Enfoque tomado
├── Testing: Cómo se testeó
├── Screenshots: Si es cambio de UI
└── Contexto completo
SELECCIÓN DE REVISOR:
─────────────────────────────────────
├── Experto del dominio
├── Alguien no familiarizado (ojos frescos)
├── No siempre la misma persona
├── Rotar revisores
├── Balancear carga
└── Revisores correctos
TIMELINE DE REVIEW:
─────────────────────────────────────
├── Solicitar review → Dentro de 24 horas
├── Feedback abordado → Mismo día si pequeño
├── No bloquear por días
├── Atención prioritaria
└── Ciclo de feedback rápido
Dando Reviews
Feedback Efectivo
DANDO REVIEWS
═════════════
QUÉ BUSCAR:
─────────────────────────────────────
Alta prioridad:
├── Correctitud: ¿Funciona?
├── Edge cases: ¿Qué podría fallar?
├── Seguridad: ¿Vulnerabilidades?
├── Diseño: ¿Es mantenible?
├── Testing: ¿Tests adecuados?
└── Issues importantes
Menor prioridad:
├── Performance (a menos que ruta crítica)
├── Issues menores de estilo
├── Nit-picks
├── Preferencias personales
└── Dejar que automatización maneje
CÓMO DAR FEEDBACK:
─────────────────────────────────────
Haz preguntas:
├── "¿Qué pasa si X es null?"
├── "¿Consideraste el enfoque Y?"
├── "¿Podría simplificarse esto?"
└── Tono colaborativo
Explica por qué:
├── No: "Usa X en vez de Y"
├── Sino: "X sería más claro aquí porque..."
├── Entendimiento, no órdenes
└── Educativo
Etiqueta el feedback:
├── [Must fix]: Issues bloqueadores
├── [Sugerencia]: Mejoras opcionales
├── [Nit]: Muy menor, no bloquea
├── [Pregunta]: Buscando entender
└── Expectativas claras
EJEMPLO DE BUEN FEEDBACK:
─────────────────────────────────────
"[Sugerencia] Considera extraer esta
lógica a una función separada—haría
el testing más fácil y la función
principal más legible. ¡Feliz de
discutir si lo ves diferente!"
Recibiendo Reviews
Manejo del Feedback
RECIBIENDO FEEDBACK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MENTALIDAD: │
│ • El código no eres tú │
│ • El feedback es sobre mejorar el código │
│ • Asume buena intención │
│ • Oportunidad de aprender │
│ │
│ RESPONDIENDO: │
│ ├── Agradecer el feedback │
│ ├── Abordar cada comentario │
│ ├── Explicar razonamiento si difiere │
│ ├── Preguntar para aclarar si no está claro │
│ └── Marcar resuelto cuando se aborda │
│ │
│ CUANDO NO ESTÁS DE ACUERDO: │
│ ├── Explicar tu razonamiento │
│ ├── Citar evidencia o documentación │
│ ├── Proponer compromiso │
│ ├── Escalar a tercero si es necesario │
│ └── Mantener profesionalismo │
│ │
└─────────────────────────────────────────────────────────────┘
Automatización
Automatizar lo Automatable
DEJAR QUE LA AUTOMATIZACIÓN MANEJE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AUTOMATIZADO: HUMANOS REVISAN: │
│ ├── Formato de código ├── Correctitud de lógica │
│ ├── Reglas de linting ├── Decisiones de diseño │
│ ├── Verificaciones de tipo ├── Claridad/legibilidad │
│ ├── Ejecución de tests ├── Edge cases │
│ ├── Cobertura de código ├── Implicaciones seguridad│
│ ├── Escaneo de seguridad ├── Calidad de tests │
│ └── Análisis de complejidad └── Calidad documentación │
│ │
│ HERRAMIENTAS A CONFIGURAR: │
│ ├── ESLint / Prettier / Black │
│ ├── Pre-commit hooks │
│ ├── CI checks que bloquean merge │
│ ├── Codecov / Coveralls │
│ └── SonarQube / CodeClimate │
│ │
│ BENEFICIO: │
│ Humanos enfocan en lo que importa, │
│ no discuten sobre espacios vs tabs │
│ │
└─────────────────────────────────────────────────────────────┘
Cultura de Review
Construyendo Buenas Prácticas
CULTURA DE REVIEW SALUDABLE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRINCIPIOS: │
│ • Reviews son sobre aprender, no criticar │
│ • Todos revisan, no solo seniors │
│ • Velocidad importa—no bloquear por días │
│ • Consistencia sobre perfección │
│ │
│ PRÁCTICAS: │
│ • Rotar revisores para dispersar conocimiento │
│ • Celebrar buenas contribuciones │
│ • Retrospectivas sobre proceso de review │
│ • Documentar patrones comunes en guía de estilo │
│ │
│ MÉTRICAS A MONITOREAR: │
│ • Tiempo promedio de review │
│ • Distribución de carga de review │
│ • Bugs encontrados en review vs producción │
│ • Satisfacción del equipo con proceso │
│ │
└─────────────────────────────────────────────────────────────┘