Los equipos que reducen la revisión de código a esperar "la aprobación del senior developer" no controlan calidad, solo pierden tiempo. Si el proceso de revisión no es medible —si no se rastrean time-to-review, comment density, PR size— el procedimiento se convierte en un cuello de botella basado en preferencia personal. En Roibase llevamos 8 años implementando un sistema donde la revisión tiene métrica, no hay conflictos personales: aprobación o pregunta clara dentro de 24 horas, PR rechazadas si superan 300 líneas, la densidad de comentarios se monitorea en las retrospectivas del sprint.

Fundamentos Medibles de la Cultura de Revisión

Rescatar la revisión de código del hábito "que lo vea el senior y lo apruebe" requiere anclar el proceso a criterios medibles. La métrica time-to-review —tiempo desde que se abre una PR hasta el primer comentario o aprobación— es el indicador más claro de la disciplina del equipo. En Roibase este tiempo se limita a 24 horas: PR abierta, dentro de 24 horas o se completa la revisión o llega la pregunta "¿puedes aclarar estos 3 puntos?". Silencio de 48 horas no es aceptable —es la regla fundamental del workflow asincrónico.

La comment density —relación entre número de comentarios y líneas modificadas— revela la profundidad de la revisión. Si es muy baja (por debajo de 0.01) significa revisión superficial; si es muy alta (por encima de 0.15) probablemente la PR es demasiado compleja o mal planificada en scope. La proporción ideal está entre 0.03-0.08: una PR de 300 líneas debe tener 9-24 comentarios. Esta relación se monitorea al final del sprint, permitiendo detectar "la densidad de revisión bajó esta iteración".

La regla de tamaño de PR es clara: cambios que superen 300 líneas no caben en una sola PR. Excepciones: actualización de dependencias o migraciones auto-generadas. Esta regla se aplica con rigor —si alguien abre una PR de 350 líneas, un bot automático comenta: "límite de tamaño superado, divide en PRs más pequeñas". Una feature grande se divide en 3 PRs: API backend + integración frontend + pulido de UI. Cada PR debe ser revisable y mergeable independientemente —no hay lugar para diffs monolíticos en ningún proceso de revisión.

Workflow Asincrónico: Sin Necesidad de Reuniones Síncronas

La reunión de revisión sincrónica —"venga, pasamos 30 minutos revisando esta PR"— es un error de time-boxing. La revisión es asincrónica: el revisor inspecciona la PR durante su bloque de deep work, deja comentarios inline, abre threads. El autor responde en su propio bloque de tiempo. Los pings síncronos en Slack están prohibidos —"¿puedes revisar esta PR ya mismo?" no es aceptable.

La solicitud de revisión se hace en GitHub con etiquetas: /cc @revisor o automáticamente con el archivo CODEOWNERS. El revisor aprueba o formula preguntas dentro de 24 horas. Si hay preguntas, el autor responde dentro de 12 horas o hace un nuevo commit. La segunda ronda de revisión se completa dentro de 12 horas. El ciclo total no supera 48 horas —este es el objetivo de cycle time.

Los threads de comentarios inline se resuelven o se etiquetan como "later" para moverse a issues. La ambigüedad "lo discutimos después" no existe —o se resuelve inmediatamente o se convierte en un issue del backlog y la PR se mergea. Los bloqueadores de revisión deben ser claros: bug de seguridad, breaking change en API, regresión de performance. Las discusiones de estilo de código no son bloqueadores —el linter ya está ahí, los detalles de preferencia pueden cerrarse con "resolve without change".

Bot de Revisión: Control Automático, Esfuerzo Manual Enfocado

Los checks automáticos en la pipeline de CI reducen la carga de revisión: linter (ESLint, Prettier), cobertura de tests en diff (código nuevo debe tener al menos 80%), cambios en bundle size (+50KB activa alarma), escaneo de seguridad (npm audit). Estos checks deben pasar antes de solicitar revisión —sin luz verde no sale de draft.

Automatización de bloqueadores de revisión: si "TODO" o "FIXME" aparecen en el mensaje del commit, la PR es rechazada. Si hay cambios en endpoints de API (modificación de decoradores @app.route), la documentación de API debe actualizarse en la misma PR —si no, el bot coloca un bloqueador. Estas reglas permiten que la revisión manual se enfoque en profundidad semántica: ¿la lógica de negocio es correcta?, ¿se manejan casos extremos?, ¿hay escenarios de test faltantes?

Categorías de Comentarios: Nit, Question, Blocker

Cada comentario de revisión se categoriza —el revisor añade etiqueta mientras escribe. nit: cuestión de preferencia, no bloquea merge ("este nombre de variable podría ser más descriptivo"). question: no entiendo, explica ("¿cuál es el caso extremo de este regex?"). blocker: no se puede mergear sin arreglar ("falta null check, se puede crashear en producción").

Los comentarios nit pueden cerrarse con "resolve without change" —el autor dice "entendido, pero no lo cambio en esta PR, lo haré en el siguiente refactor", el revisor aprueba. Las preguntas se responden en el thread, y si la explicación es suficiente se resuelven. Los bloqueadores requieren siempre un nuevo commit —mientras haya bloqueadores sin resolver, el botón de merge está deshabilitado (regla de GitHub branch protection).

La métrica comment density separa estas categorías: si blocker density es mayor al 20%, el scope de la PR fue mal planificado; si nit density supera 60%, la revisión es superficial —primero arregla la configuración del linter. La distribución ideal: 15% blocker, 50% question, 35% nit. En retrospectiva del sprint se discuten estos porcentajes: "Este sprint aumentó el ratio de blocker, la fase de planeación de PRs se debilitó".

Lugar de las Métricas de Revisión en la Retrospectiva del Sprint

Al final de cada sprint se abre el dashboard de revisión: time-to-review promedio, distribución de tamaños de PR, histograma de comment density, archivos más revisados, distribución de carga de revisión (quién tiene cuántas PRs pendientes). Estas métricas transforman discusiones subjetivas sobre "¿mejora la calidad del código?" en datos concretos.

Si time-to-review supera 36 horas —el objetivo es 24— se analiza por qué: ¿el revisor está sobrecargado?, ¿las PRs se abren fuera de horario?, ¿hay mucho context switching? Si hay desequilibrio de carga (un developer revisó 12 PRs, otro 2) se rota el archivo CODEOWNERS. Si las PRs se abren fuera de horario, el workflow asincrónico está roto —el equipo debe sincronizarse en fase draft, abrir cuando esté ready.

Si comment density bajó —sprint anterior 0.05, este 0.02— la profundidad de revisión disminuyó. Esto ocurre típicamente en períodos de alta velocidad: todos enfocados en entregar features, revisiones superficiales. En retrospectiva se decide "mientras subimos velocity, no puede bajar la calidad de revisión, debemos hacer PRs más pequeñas para acelerar el ciclo". Sin métrica esta detección es imposible —todos dicen "revisamos bien", pero los datos dicen lo opuesto.

Sin Conflictos, Sistema Hay

Los conflictos en revisión surgen de desorden sistémico: no queda claro qué es bloqueador, cuándo se puede mergear, quién revisa cuándo. Si el sistema es claro no hay conflicto: la regla de 24 horas se aplica, si se viola el autor escala (menciona al tech lead), PRs de 350 líneas las rechaza un bot, comentarios bloqueador no resueltos previenen merge. Todos juegan con las mismas reglas, no hay opinión personal.

El feedback de revisión se dirige al código, no a la persona: en lugar de "siempre haces esto mal" se dice "este archivo carece del patrón null check que está en otros handlers". En retrospectiva no aparecen nombres de personas: en lugar de "developer X no revisa" se dice "la métrica time-to-review está por encima del objetivo, vamos a rebalancear la distribución de carga". La métrica proporciona objetividad —todos ven los números en el dashboard, la discusión se resuelve.

La cultura de code review está tan ligada a la identidad del equipo como el branding: cuando el equipo dice "nosotros revisamos en 24 horas, no abrimos PRs de más de 300 líneas" esa disciplina se integra desde el onboarding. El nuevo developer en su primer PR ve estas reglas, se adapta a la cultura. El sistema no depende de liderazgo subjetivo —si cambia el líder las métricas continúan.

Time-to-review de 24 horas, PR size de 300 líneas, comment density 0.03-0.08 —estos números pueden variar en tu equipo. Lo importante es que existan, se midan y se discutan en retrospectiva. La cultura de revisión de código no es la aprobación subjetiva del senior, es el diseño sistemático disciplinado del equipo. Si revisas sin sistema no controlas calidad, solo creas cuello de botella. Lo que toca hacer ahora: medir el time-to-review promedio de tus últimas 10 PRs; si supera 48 horas, inicia un análisis de causas.