El análisis dentro de la revisión de código

El análisis puede correr sobre todo el repositorio o solo sobre las líneas que cambia cada propuesta. Lo habitual es lo segundo para bloquear, y fijar una línea base: los hallazgos que ya existían el día que se activó el control quedan registrados y la fusión solo se bloquea por los nuevos. Si se bloqueara por todo, el primer día la cadena quedaría parada por una deuda que nadie introdujo en esa propuesta, y la reacción previsible es apagar el control. La deuda previa no se olvida: se trata con su propio plan y su propio plazo, aparte de las propuestas.

Además, el control solo protege si es obligatorio: un check que se puede saltar es una sugerencia.

Excluir carpetas del análisis es legítimo cuando el código no se despliega: las pruebas, las simulaciones. Pero cada exclusión es una zona donde el control no mira, y por eso merece lo mismo que una supresión: motivo concreto, responsable, fecha de revisión y la comprobación de que lo excluido no viaja a producción. «Demasiado ruido» no es un motivo: es el síntoma de una regla que hay que afinar.

La política de Naranjal mantiene una lista de carpetas excluidas. Una de ellas no cumple ninguna de las condiciones.

Para saber si una exclusión está ocultando algo, se repite el análisis sin ella sobre una muestra de propuestas y se comparan las dos columnas: lo que mostró el análisis tal como está y lo que muestra sin excluir nada. Donde las cifras no coinciden hay código que cambió dentro de la zona ciega. Es una prueba barata y debería ser parte de la revisión periódica de la política.

La tabla de la semana trae las dos columnas para cinco propuestas.

Una vez descubierta la diferencia, la cifra que importa es el total real de hallazgos nuevos que entraron en la semana, no el que mostraba el control. Es el número que le llevas a quien decide si se quita la exclusión: con una cuenta incorrecta, el argumento se desmorona en la primera objeción.

Suma con cuidado y comprueba que el total de la columna que elijas corresponde a las cinco propuestas.

El análisis y la persona que revisa cubren cosas distintas. La máquina cubre patrones: lo que tiene forma reconocible, en todas las líneas, sin cansarse. La persona cubre lo que no tiene forma: quién puede llamar a un endpoint nuevo, si el cambio respeta la regla del negocio, si el diseño abre una puerta que antes estaba cerrada. Un check en verde significa «no encontré ninguno de los patrones que conozco», no «el cambio es seguro». Si el revisor lo toma por revisión, el reparto se rompe y nadie mira la mitad del trabajo.

Los comentarios de la semana muestran un caso: una aprobación que se apoyó solo en el verde.