Tu code review probablemente está roto
La mayoría de las code reviews detectan entre el 15 y el 30 por ciento de los defectos que deberían encontrar. Eso no es una suposición. IBM lo midió en los años 70, y estudios en AT&T, HP y Microsoft han confirmado el mismo rango década tras década.
La revisión informal es barata, asíncrona y socialmente aceptable. También es mayormente inefectiva para encontrar bugs. Los ingenieros leen demasiado rápido, saltan los error paths y evitan señalar problemas reales porque nadie quiere ser quien detenga el merge.
Existe una alternativa que reporta consistentemente tasas de eliminación de defectos del 60 al 90 por ciento. Fue inventada en IBM en 1976 por Michael Fagan. No requiere herramientas, IA ni presupuesto. Sí requiere algo que la mayoría de los equipos de ingeniería se niegan a dar: estructura.
¿Qué es una Fagan inspection?
Una Fagan inspection es un proceso de revisión formalmente definido, de múltiples pasos, con roles específicos, límites de tiempo, criterios de entrada y checklists. A diferencia de un típico pull request review, no es una conversación entre autor y revisor. Es una reunión estructurada con un moderador, un reader, inspectores y el autor.
El autor permanece mayormente en silencio. La reunión tiene un timebox estricto. Y el único objetivo es encontrar defectos.
El proceso sigue seis pasos:
-
Planning. El moderador selecciona el material, verifica los entry criteria, asigna roles y programa la reunión. Los entry criteria existen por una razón. No se inspecciona un borrador. El documento debe estar completo, compilable y probado antes de tener derecho a consumir el tiempo de cuatro personas.
-
Overview. Opcional. El autor explica contexto si los inspectores no están familiarizados con el dominio.
-
Preparation. Cada inspector revisa el material solo antes de la reunión. Esto es innegociable. No se llega sin preparación. Los inspectores usan checklists adaptadas a tipos comunes de defectos y anotan issues de forma privada.
-
Inspection. La reunión en sí. El reader, quien no escribió el código, lo recorre línea por línea y parafrasea en voz alta. Los inspectores plantean issues cuando detectan discrepancias. El autor escucha. Nadie propone fixes. El moderador impone los límites de tiempo y mantiene la reunión enfocada únicamente en la identificación de defectos.
-
Rework. El autor corrige los defectos.
-
Follow-up. El moderador verifica que cada defecto fue atendido. Si se encontraron demasiados defectos, ocurre una reinspection.
Cuatro roles mantienen el proceso honesto. El moderador planifica y controla. El autor creó el trabajo y responde preguntas solo cuando se le preguntan. El reader parafrasea el código durante la reunión, forzando una comprensión más lenta y cuidadosa. Los inspectores, generalmente de dos a cuatro personas, encuentran los defectos.
Por qué la revisión informal falla donde las Fagan inspections triunfan
La diferencia no es talento. Es diseño de proceso.
En un típico pull request review, el revisor lee el diff en el navegador, hojea el happy path, deja algunos comentarios y aprueba. No hay tiempo de preparación. No hay checklist. No hay un mecanismo que fuerce al revisor a examinar el error handling o las boundary conditions. Las dinámicas sociales premian la velocidad y la cortesía, no la minuciosidad.
Las Fagan inspections invierten esos incentivos.
La preparación individual significa que cada inspector ha leído el código antes de que empiece la reunión. La paráfrasis del reader fuerza al grupo a procesar el código a velocidad de comprensión en lugar de velocidad de hojeada. Las checklists dirigen la attention hacia categorías conocidas de defectos en lugar de lo que llama la attention. La presión del tiempo evita que la reunión se desvíe en debates de diseño. Y separar la búsqueda de defectos de la corrección evita que el grupo se ancle en la primera solución que alguien sugiere.
El resultado es que las Fagan inspections detectan la mayoría de los defectos antes de que lleguen a testing o production.
El costo está cargado al frente en person-hours.
El verdadero trade-off: Person-hours vs. defect escape
He aquí por qué la mayoría de los equipos no usan Fagan inspections.
Una sola inspection requiere de cuatro a seis personas en una sala durante hasta dos horas para revisar aproximadamente 250 líneas de código. Eso son de 8 a 12 person-hours para un cambio pequeño. En un workflow moderno de CI/CD donde los equipos despliegan varias veces al día, esto parece absurdo.
El proceso también se siente burocrático. Entry criteria, roles formales, checklists impresas, verificación de follow-up. La mayoría de los ingenieros lo odiarán por principio. Y no escala a diffs grandes. Un refactor de dos mil líneas requeriría ocho reuniones de inspection separadas.
Pero el cálculo cambia cuando miras el costo total en lugar del costo de la reunión.
Los datos originales de IBM mostraron que encontrar y corregir un defecto durante la inspection costaba aproximadamente una décima parte de lo que costaba encontrar y corregir el mismo defecto durante el testing. Cuando escapaba a production, la relación crecía a veinte o treinta a uno.
Así que sí, la inspection es cara. Aún así es más barata que debuggear production incidents, quemar capacidad de sprint en fixes reactivos y perder la confianza del cliente.
El problema es que los ahorros son invisibles. No puedes medir el bug que evitaste. El costo de la reunión es inmediato y obvio. Por eso la revisión informal gana en la mayoría de las organizaciones. Optimiza para la velocidad visible sobre la calidad invisible.
Ejecutando una Fagan inspection ligera en 2026
No necesitas adoptar toda la ceremonia. La mayoría de los equipos pueden obtener el setenta por ciento del beneficio con el veinte por ciento del overhead manteniendo las core mechanics y eliminando el papeleo.
He aquí una secuencia práctica:
Requiere preparación individual antes de cualquier revisión sincrónica. Si no has leído el código, no asistes.
Asigna un reader que no escribió el código para que recorra la lógica en voz alta. No dejes que el autor dirija. Parafrasear fuerza al grupo a procesar cada branch.
Usa una checklist adaptada a los tipos de defectos más comunes de tu equipo. Comienza con la lista de abajo y agrega items a medida que aprendas de defectos escapados.
Timebox a noventa minutos. Termina a tiempo, aunque no hayas terminado. Programa una segunda sesión en lugar de dejar que la fatiga destruya la calidad.
Mantén al autor pasivo. Responden solo preguntas aclaratorias. Sin defender decisiones de diseño.
Registra defectos, no soluciones. Corrige los defectos después de la reunión.
Para concretar esto, aquí hay un pequeño script en Python que planea una inspection, estima el tiempo e imprime checklists específicas por rol:
#!/usr/bin/env python3
"""
Plan a Fagan-style inspection: estimate time and emit checklists.
"""
import argparse
def count_lines(filepath):
"""Count non-blank lines."""
try:
with open(filepath, "r") as f:
return sum(1 for line in f if line.strip())
except Exception:
return 0
def plan_inspection(files, rate=125):
"""
rate: reviewable lines per hour. Fagan recommended 100-125 for code.
"""
total = sum(count_lines(f) for f in files)
hours = total / rate
minutes = hours * 60
print(f"Total reviewable lines: {total}")
print(f"At {rate} lines/hour, schedule: {hours:.1f} hours ({minutes:.0f} min)")
if hours > 2:
sessions = int(hours / 2) + 1
print(f"WARNING: exceeds 2-hour limit. Split into {sessions} sessions.")
print("\n--- ROLE: Reader ---")
print("Paraphrase each block aloud. Do not just read variable names.")
print("Pause at every conditional, loop boundary, and API call.")
print("\n--- ROLE: Inspector ---")
checklist = [
"Off-by-one in loops and array or slice access",
"Null, None, or undefined dereferences",
"Resource leaks: files, connections, locks, contexts",
"Error paths: are they handled, returned, and tested?",
"Return values: are they checked before use?",
"Shared mutable state and thread safety",
"Boundary conditions and input validation",
"Invariant violations: what should stay true, and does it?",
]
for item in checklist:
print(f" [ ] {item}")
print("\n--- ROLE: Moderator ---")
print("Start on time. End on time.")
print("No design debates. No solution proposals.")
print("Record each defect with: file, line, severity, type.")
if __name__ == "__main__":
parser = argparse.ArgumentParser(description="Plan a Fagan inspection")
parser.add_argument("files", nargs="+", help="Source files to inspect")
parser.add_argument("--rate", type=int, default=125, help="Lines per hour")
args = parser.parse_args()
plan_inspection(args.files, args.rate)Guárdalo como inspect.py, ejecuta python inspect.py src/auth.py src/orders.py, y tendrás una estimación de tiempo y una checklist.
Preguntas frecuentes
¿Qué es una Fagan inspection?
Una Fagan inspection es un proceso de revisión estructurado de seis pasos con roles definidos, criterios de entrada y checklists. Fue desarrollado por Michael Fagan en IBM en 1976 para encontrar defectos en productos de trabajo de software antes del testing.
¿En qué se diferencia una Fagan inspection de un pull request review?
Un pull request review es típicamente asíncrono, informal y dirigido por el autor. Una Fagan inspection es una reunión sincrónica con roles asignados, preparación individual obligatoria, límites de tiempo estrictos y una regla de que el autor permanece en silencio mientras otros encuentran defectos.
¿Por qué no son más comunes las Fagan inspections?
Son caras en person-hours, se sienten burocráticas para equipos modernos y no escalan bien a cambios grandes y frecuentes. El costo es visible e inmediato. Los defectos evitados son invisibles.
¿Pueden funcionar las Fagan inspections en un entorno ágil o CI/CD?
Sí, pero con modificaciones. La mayoría de los equipos usan versiones ligeras: preparación individual obligatoria, un reader que parafrasea, una checklist y un timebox estricto. El proceso formal completo usualmente se reserva para modules críticos o de alto riesgo.
Pruébalo en un module
No necesitas reescribir tu proceso. Elige un module que haya tenido defectos escapados en el último mes. Reúne a tres ingenieros que no lo escribieron. Dales el código y una checklist con veinticuatro horas de anticipación. Programa noventa minutos. Asigna un reader. Haz que el autor escuche.
Mide lo que encuentres. Luego decide si la reunión costó más de lo que habrían costado los bugs.
Si quieres los datos originales, el paper de 1976 de Fagan “Design and Code Inspections to Reduce Errors in Program Development” sigue siendo la mejor referencia. Tiene cincuenta años, y la mayoría de los equipos aún no han alcanzado ese nivel.