Code review lento mata productividad del equipo

El problema real con code review

En la mayoría de equipos, el code review es donde van a morir los pull requests. Un dev termina su feature un martes y recién se mergea el viernes. Mientras tanto, el resto del equipo está bloqueado, los conflicts se acumulan y la productividad se va al tacho.

No es que el code review sea malo. Es que lo estamos haciendo mal.

La diferencia entre equipos que entregan rápido y equipos que se traban está en cómo manejan las revisiones de código. Los primeros usan code review para acelerar. Los segundos, sin darse cuenta, lo convierten en el cuello de botella más caro del proceso.

Tamaño importa: pull requests pequeños

La regla más importante: si tu PR tiene más de 400 líneas de código, ya perdiste.

Un PR grande es imposible de revisar bien. Los reviewers se cansan, aprueban sin leer o dejan pasar bugs obvios. Además, genera merge conflicts y bloquea a otros desarrolladores.

Técnicas para PRs chicos:

• Feature flags: Subí código incompleto pero funcional detrás de un flag
• Refactors separados: No mezcles refactor con nueva funcionalidad
• Commits atómicos: Cada commit debería compilar y pasar tests
• Stacked PRs: Cadena de PRs pequeños que se van mergeando

Ejemplo práctico: en lugar de subir toda la feature de login de una vez, hacés:

1. PR con el endpoint básico
2. PR con validaciones
3. PR con el frontend
4. PR con tests de integración

Cada uno se revisa y mergea rápido.

Automatizá lo que se puede automatizar

Si tus reviewers están perdiendo tiempo en formato de código, naming conventions o tests faltantes, estás desperdiciando el recurso más caro: el tiempo del senior.

Checklist de automatización:

• Linting automático: ESLint, Prettier, Black, etc.
• Tests obligatorios: No se puede mergear sin coverage mínimo
• CI que bloquea: Si no compila o fallan tests, ni siquiera se puede revisar
• Danger.js o similar: Chequeos automáticos de tamaño de PR, archivos modificados, etc.
• Pre-commit hooks: Que formateen y corran tests básicos antes del push

Todo lo que pueda hacer una máquina, que lo haga la máquina.

El arte del comentario útil

La mayoría de comentarios en code review son ruido. "Cambiar esta variable por algo más descriptivo" no ayuda a nadie.

Comentarios que sí sirven:

En lugar de: "Esto está mal" Mejor: "Esto puede generar memory leak si el usuario cierra la ventana antes de que termine el request. Podés usar AbortController."

En lugar de: "Usar map acá" Mejor: "Con map() esto queda más claro y es más performante para arrays grandes."

En lugar de: "Falta manejo de errores" Mejor: "¿Qué pasa si la API devuelve 500? El usuario va a ver una pantalla en blanco."

Tipos de comentarios por prioridad:

1. Bugs evidentes: Siempre bloquean el merge
2. Security issues: Siempre bloquean
3. Performance crítico: Bloquea si impacta usuarios
4. Arquitectura: Solo si rompe patrones establecidos del proyecto
5. Naming y estilo: Solo si es realmente confuso

Timing: cuándo revisar

El momento importa tanto como el contenido. Un PR que se revisa 3 días después es un PR que va a generar conflicts y va a frenar todo el pipeline.

Estrategias de timing efectivas:

Notifications inteligentes: Configurá Slack o similar para que notifique PRs pendientes cada 2 horas durante horario laboral.

Review scheduling: Algunos equipos tienen slots fijos. Por ejemplo, todos revisan a las 11am y a las 3pm.

Round robin automático: Herramientas como PullAssigner asignan reviewers automáticamente, balanceando la carga.

WIP y Draft PRs: Usá draft PRs para feedback temprano sin bloquear el workflow principal.

Context switching mata la productividad

Cada vez que un dev para lo que está haciendo para revisar código, pierde entre 15-30 minutos volviendo al contexto anterior.

La solución no es "revisar menos", sino revisar más inteligentemente.

Batching de reviews:

• Agendá bloques de 30-45 minutos solo para reviews
• Revisá varios PRs juntos en lugar de uno por vez
• Usá herramientas como Refined GitHub para ver todos los PRs pendientes de una vez

Priorización clara:

• P0: Hotfixes y bugs críticos (revisar inmediatamente)
• P1: Features en el sprint actual (revisar el mismo día)
• P2: Refactors y mejoras (revisar en 24-48hs)

Cultura de ownership distribuido

En muchos equipos, solo el tech lead o senior revisa código. Eso crea un cuello de botella y desperdicia oportunidades de aprendizaje.

Estrategias para distribuir reviews:

Pair reviewing: Dos devs revisan juntos PRs complejos. Uno conduce, el otro pregunta y señala.

Junior + Senior: Los juniors hacen la primera pasada buscando bugs obvios y questions de negocio. Los seniors se enfocan en arquitectura y performance.

Domain experts: La persona que más conoce esa área del código siempre está en el review, independientemente de seniority.

Métricas que importan

Si no medís, no podés mejorar. Pero la mayoría de equipos miden las métricas equivocadas.

Métricas útiles:

• Time to first review: Cuánto tarda alguien en hacer el primer comentario
• Merge time: Desde que se abre el PR hasta que se mergea
• Review rounds: Cuántas idas y vueltas antes del merge
• PR size distribution: Qué porcentaje de PRs son > 400 líneas

Métricas que no sirven:

• Cantidad de comentarios por PR (incentiva bikeshedding)
• Líneas de código revisadas por persona (incentiva PRs grandes)
• Porcentaje de PRs rechazados (incentiva aprobar todo)

Herramientas que aceleran el proceso

La tooling correcta puede reducir el friction del code review a casi cero.

Must-have:

• GitHub CLI o similar: Para crear, revisar y mergear PRs desde terminal
• Browser extensions: Refined GitHub, Octotree para navegar código más fácil
• IDE integration: Plugins que muestran PRs pendientes directamente en VS Code
• Automated merging: Auto-merge cuando todos los checks pasan y hay approval

Nice-to-have:

• Review checklist templates: Diferentes templates según tipo de cambio
• Code tour tools: Para explicar cambios complejos con annotaciones
• Async video reviews: Loom o similar para explicar cambios complejos

Preguntas frecuentes

¿Qué hago si los seniors no tienen tiempo para revisar? Implementá "gradual review": juniors y mids hacen la primera pasada, seniors solo ven arquitectura y security. Usá automation para todo lo demás.

¿Cómo manejar disagreements en code review? Establecé un "reviewer hierarchy" claro. Si hay disagreement, escala al tech lead o architect. No dejes que los PRs se traben en discusiones infinitas.

¿Vale la pena hacer code review en proyectos chicos o MVPs? Sí, pero adaptado. En lugar de reviews detallados, hacé "live reviews" donde revisás el código mientras lo escribís en pair programming.