10 min lectura • Guide 35 of 877
Configurando Workflows Efectivos de Code Review
Las code reviews son críticas para mantener calidad, compartir conocimiento y detectar bugs antes de producción. Pero procesos de revisión mal diseñados pueden convertirse en cuellos de botella que frustran desarrolladores y ralentizan entregas. Las integraciones y features de workflow de GitScrum ayudan a establecer prácticas de revisión que son exhaustivas pero eficientes.
El Desafío del Code Review
Problemas comunes de revisión:
| Problema | Impacto |
|---|---|
| Reviews toman mucho tiempo | PRs se acumulan, contexto perdido |
| Estándares inconsistentes | Calidad varía por revisor |
| Expectativas poco claras | Nitpicking vs. feedback importante |
| Cuellos de botella de revisores | Una persona bloquea todos los PRs |
| Sin responsabilidad | Reviews ignorados o retrasados |
Configuración de Integración GitScrum
Conectando Proveedores Git
Integración Proveedor Git:
PLATAFORMAS SOPORTADAS:
├── GitHub (Cloud & Enterprise)
├── GitLab (Cloud & Self-hosted)
└── Bitbucket (Cloud & Server)
PASOS DE CONEXIÓN:
1. Settings → Integrations → Git Providers
2. Seleccionar proveedor
3. Autorizar conexión OAuth
4. Elegir repositorios a conectar
5. Configurar ajustes de sincronización
OPCIONES DE SYNC:
┌─────────────────────────────────────────────────────────────┐
│ Configuración Integración Git │
├─────────────────────────────────────────────────────────────┤
│ Repositorio: acme/frontend │
│ │
│ Ajustes de Sync: │
│ ☑ Vincular branches a tareas (patrón: TASK-###) │
│ ☑ Vincular PRs a tareas │
│ ☑ Actualizar estado de tarea en eventos PR │
│ ☑ Mostrar estado PR en detalles de tarea │
│ ☑ Importar comentarios PR como comentarios de tarea │
│ │
│ Mapeo de Estados: │
│ PR Abierto → Mover tarea a: [En Revisión ▼] │
│ PR Aprobado → Mover tarea a: [Aprobado ▼] │
│ PR Mergeado → Mover tarea a: [Hecho ▼] │
│ PR Cerrado → Mover tarea a: [Sin cambio ▼] │
└─────────────────────────────────────────────────────────────┘
Vinculación Automática de Tareas
Convención de Nombres de Branch:
PATRÓN: [tipo]/TASK-[id]-[descripción]
Ejemplos:
├── feature/TASK-456-user-search
├── fix/TASK-789-login-bug
├── refactor/TASK-101-cleanup-auth
└── chore/TASK-202-update-deps
Flujo de Auto-Detección:
┌─────────────────────────────────────────────────────────────┐
│ 1. Developer crea branch: │
│ git checkout -b feature/TASK-456-user-search │
│ │
│ 2. GitScrum detecta patrón "TASK-456" │
│ │
│ 3. Tarea TASK-456 auto-actualizada: │
│ ├── Estado: → En Progreso │
│ ├── Branch: feature/TASK-456-user-search │
│ └── Actividad: "Branch creada por @alice" │
│ │
│ 4. Cuando PR se abre: │
│ ├── PR vinculado a tarea │
│ ├── Estado: → En Revisión │
│ └── Actividad: "PR #123 abierto" │
│ │
│ 5. Cuando PR se mergea: │
│ ├── Estado: → Hecho │
│ └── Actividad: "PR #123 mergeado a main" │
└─────────────────────────────────────────────────────────────┘
Asignación de Revisores
Reglas de Asignación Automatizada
Configuración de Asignación de Revisores:
ESTRATEGIAS DE ASIGNACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ Reglas de Asignación de Revisores │
├─────────────────────────────────────────────────────────────┤
│ │
│ Estrategia: [Round Robin ▼] │
│ │
│ Opciones: │
│ ├── Round Robin: Rotar entre miembros del equipo │
│ ├── Load Balanced: Asignar a persona con menos reviews │
│ ├── Code Ownership: Basado en paths de archivo cambiados │
│ ├── Aleatorio: Selección random del pool │
│ └── Manual: Autor selecciona, con sugerencias │
│ │
│ Pool de Revisores: [Equipo Frontend ▼] │
│ ├── @alice (senior) │
│ ├── @bob (senior) │
│ ├── @carol (mid) │
│ └── @david (mid) │
│ │
│ Revisores Requeridos: [2] │
│ │
│ Reglas: │
│ ☑ Al menos 1 revisor senior │
│ ☑ No puede revisar sus propios PRs │
│ ☑ Excluir en PTO (sync desde calendario) │
│ □ Requerir revisor específico para [security/*] │
└─────────────────────────────────────────────────────────────┘
Mapeo de Ownership de Código
Asignación estilo CODEOWNERS:
Reglas de Path de Archivo:
┌─────────────────────────────────────────────────────────────┐
│ Configuración de Ownership de Código │
├─────────────────────────────────────────────────────────────┤
│ │
│ Patrón Path Owners Requerido │
│ ───────────────────────────────────────────────────────────│
│ /src/api/* @api-team 1 │
│ /src/components/ui/* @ui-team 1 │
│ /src/auth/* @security-team 2 │
│ /src/payments/* @payments-lead 1 + @security │
│ /database/* @dba-team 1 │
│ *.sql @dba-team 1 │
│ /tests/* @qa-lead Opcional │
│ * @default-reviewers 1 │
│ │
│ Prioridad: Primera coincidencia gana (arriba a abajo) │
└─────────────────────────────────────────────────────────────┘
Balanceo de Carga de Reviews
Asignación Balanceada por Carga:
CARGA DE REVIEW ACTUAL:
┌─────────────────────────────────────────────────────────────┐
│ CARGA DE TRABAJO REVISORES [Esta Semana] │
├─────────────────────────────────────────────────────────────┤
│ │
│ Reviews Activos: │
│ Alice: [██░░░░░░] 2 PRs (capacidad: 4) ← Próx asignar │
│ Bob: [████░░░░] 4 PRs (capacidad: 4) Lleno │
│ Carol: [███░░░░░] 3 PRs (capacidad: 4) │
│ David: [██░░░░░░] 2 PRs (capacidad: 4) ← Próx asignar │
│ │
│ Stats de Review Esta Semana: │
│ ├── Alice: 8 completados, avg 4h respuesta │
│ ├── Bob: 6 completados, avg 6h respuesta │
│ ├── Carol: 7 completados, avg 3h respuesta │
│ └── David: 5 completados, avg 8h respuesta │
└─────────────────────────────────────────────────────────────┘
SLAs de Review y Tracking
Expectativas Basadas en Tiempo
Configuración de SLA de Review:
┌─────────────────────────────────────────────────────────────┐
│ SLAs de Code Review │
├─────────────────────────────────────────────────────────────┤
│ │
│ SLA Primera Respuesta: │
│ ├── P0/Crítico: 2 horas │
│ ├── P1/Alto: 4 horas │
│ ├── P2/Normal: 8 horas (1 día laboral) │
│ └── P3/Bajo: 24 horas │
│ │
│ SLA Completado de Review: │
│ ├── PR Pequeño (<100 líneas): 4h después de primera resp │
│ ├── PR Mediano (100-500 líneas): 8 horas │
│ └── PR Grande (>500 líneas): 24 horas │
│ │
│ Reglas de Escalación: │
│ ├── 50% del SLA: Recordatorio al revisor │
│ ├── 100% del SLA: Notificar team lead │
│ ├── 150% del SLA: Escalar a eng manager │
│ └── 200% del SLA: Permitir merge sin review completo │
└─────────────────────────────────────────────────────────────┘
Dashboard de Estado de Review
Dashboard Pipeline de Review:
┌─────────────────────────────────────────────────────────────┐
│ PIPELINE CODE REVIEW [Últimos 7 Días ▼] │
├─────────────────────────────────────────────────────────────┤
│ │
│ Estado Actual: │
│ ├── Esperando Review: 8 PRs │
│ ├── En Review: 5 PRs │
│ ├── Cambios Solicitados: 3 PRs │
│ └── Aprobados (pendiente merge): 2 PRs │
│ │
│ Performance de SLA: │
│ │ Primera Respuesta │
│ │ A Tiempo: ████████████████████ 85% │
│ │ Tarde: ████ 15% │
│ │ │
│ │ Completado de Review │
│ │ A Tiempo: ██████████████████ 78% │
│ │ Tarde: ██████ 22% │
│ │
│ PRs con Riesgo SLA: │
│ ├── 🔴 PR #456: 6h atrasado (asignado: @bob) │
│ ├── 🟡 PR #461: 2h restantes (asignado: @carol) │
│ └── 🟡 PR #463: 3h restantes (asignado: @alice) │
└─────────────────────────────────────────────────────────────┘
Checklists de Review
Criterios de Review Estandarizados
Template Checklist de Code Review:
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST DE REVIEW PR │
├─────────────────────────────────────────────────────────────┤
│ │
│ FUNCIONALIDAD │
│ □ Código hace lo que dice la descripción de la tarea │
│ □ Casos edge están manejados │
│ □ Manejo de errores es apropiado │
│ □ Sin bugs obvios │
│ │
│ CALIDAD DE CÓDIGO │
│ □ Código es legible y auto-documentado │
│ □ Funciones/métodos tienen tamaño apropiado │
│ □ Sin duplicación de código │
│ □ Sigue convenciones y patrones del proyecto │
│ │
│ TESTING │
│ □ Unit tests cubren nueva funcionalidad │
│ □ Tests son significativos (no solo para cobertura) │
│ □ Casos edge están testeados │
│ □ Tests pasan local y en CI │
│ │
│ SEGURIDAD │
│ □ Sin datos sensibles expuestos │
│ □ Validación de input en lugar │
│ □ Autenticación/autorización correcta │
│ □ Sin vulnerabilidades SQL injection o XSS │
│ │
│ PERFORMANCE │
│ □ Sin issues obvios de performance │
│ □ Queries de DB son eficientes (sin N+1) │
│ □ Caching apropiado considerado │
└─────────────────────────────────────────────────────────────┘
Calidad de Feedback
Categorías de Comentarios
Tipos de Feedback Estructurado:
PREFIJOS DE COMENTARIO:
┌─────────────────────────────────────────────────────────────┐
│ Prefijo Significado ¿Bloquea? │
├─────────────────────────────────────────────────────────────┤
│ [BLOCKER] Debe arreglar antes de merge Sí │
│ [ISSUE] Debería arreglar, importante Sí (usualmente) │
│ [SUGGEST] Considerar cambiar No │
│ [NIT] Menor/preferencia estilo No │
│ [QUESTION] Necesita clarificación Depende │
│ [PRAISE] Buen trabajo, buen código No │
│ [FYI] Compartir información No │
└─────────────────────────────────────────────────────────────┘
Ejemplos:
[BLOCKER] Esta query SQL es vulnerable a injection.
Por favor usa queries parametrizadas.
[ISSUE] Esta función tiene 200 líneas. Considera dividir
en funciones más pequeñas para testabilidad.
[SUGGEST] Podrías simplificar esto con un reduce()
[NIT] Preferiría `isActive` sobre `active` para nombres boolean.
[PRAISE] ¡Implementación muy limpia de la capa de cache!
Workflows de Aprobación
Aprobaciones Multi-Etapa
Requisitos de Aprobación:
PR ESTÁNDAR:
┌─────────────────────────────────────────────────────────────┐
│ Requisitos para Merge: │
│ ├── 1+ aprobación del equipo │
│ ├── Todos los blockers resueltos │
│ ├── Checks de CI pasando │
│ └── Sin threads sin resolver │
└─────────────────────────────────────────────────────────────┘
ÁREAS SENSIBLES:
┌─────────────────────────────────────────────────────────────┐
│ Path: /src/auth/*, /src/payments/* │
│ Requisitos: │
│ ├── 2+ aprobaciones │
│ ├── 1 debe ser del equipo de seguridad │
│ ├── Todos los checklists completos │
│ └── CI extendido (scans de seguridad) │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
Para Autores
- Mantener PRs pequeños — <300 líneas ideal, <500 máximo
- Escribir buenas descripciones — Contexto, qué, por qué, cómo
- Auto-revisar primero — Detectar issues obvios
- Responder prontamente — Abordar feedback rápidamente
- No tomarlo personal — Reviews mejoran código, no juzgan personas
Para Revisores
- Ser oportuno — Respetar el SLA
- Ser específico — Apuntar a líneas exactas, sugerir fixes
- Ser amable — Criticar código, no personas
- Priorizar feedback — Blockers > Issues > Nits
- Aprender mientras revisas — Es compartir conocimiento
Para Equipos
- Definir estándares claros — Documentar cómo se ve lo bueno
- Rotar revisores — Expandir conocimiento
- Rastrear métricas — Mejorar con el tiempo
- Celebrar buenos reviews — Reforzar calidad
- Retrospectivas regulares — Refinar el proceso