Un umbral que rompe el build

Medir la complejidad del código está bien, pero un número que solo aparece en un reporte que nadie abre no cambia nada. La deuda técnica no entra de golpe: se cuela una función a la vez, cada una un poco peor que la anterior, ninguna lo bastante mala como para detener a nadie. Para cuando «se siente enredado», ya es tarde.

La forma de frenar esa deriva es ponerle un límite que el proceso respete por sí solo.

El build como guardia

La idea es simple: se fija un umbral de complejidad por función y se mide en cada cambio dentro de la integración continua. Si una función lo cruza, el build falla — igual que falla con un test roto o un error de tipos. No es un aviso que se pueda ignorar; es una puerta cerrada.

Un aviso se acumula. Un build roto se atiende. La diferencia entre los dos es si la regla se cumple de verdad.

Calibrar, no estrangular

El umbral correcto no es el más bajo posible. Demasiado estricto y el equipo lo desactiva en una semana; demasiado alto y no protege de nada. Conviene empezarlo por encima de lo que ya tienes —para no romper el build el primer día— e ir bajándolo a medida que se limpia el código existente.

También necesita una válvula de escape honesta: una forma explícita y visible de decir «esta función supera el umbral a propósito, y aquí está la razón». La excepción documentada es información; la excepción silenciosa es el principio del fin de la regla.

Puesto así, el umbral deja de ser burocracia y se vuelve lo que debe ser: un acuerdo del equipo sobre cuánta complejidad está dispuesto a cargar, defendido por una máquina que no se cansa ni hace excepciones por las prisas.