El juego del calamar: la luz roja del código rígido en Java

En sistemas donde cada milisegundo y cada release cuentan, la supervivencia del software depende de su capacidad de adaptarse. Inspirado en la dinámica de El juego del calamar, propongo una serie de pruebas donde el código pasa por una luz roja/luz verde. En el primer episodio, la luz roja del código rígido expone patrones que cuestan disponibilidad, time-to-market y confianza.

Rígido es todo lo que impide cambiar con seguridad: clases dios, métodos kilométricos, acoplamiento temporal y estructural, ifs encadenados que codifican reglas de negocio, excepciones atrapadas y olvidadas, nulls propagándose, configuraciones hard-coded, estados compartidos, frameworks dictando el dominio. Ese paisaje hace que cada refactor duela, la complejidad ciclomática suba y los bugs se escondan en ramas muertas.

La luz verde es la suma de decisiones pequeñas: legibilidad primero, nombres que revelan intención, funciones puras y pequeñas, composición sobre herencia, SOLID aplicado con criterio, inmutabilidad donde duele fallar, boundaries explícitos con puertos y adaptadores, DTOs y mapeos claros, Optional bien usado, excepciones significativas. Tests que anclan el comportamiento (unitarios, de contrato y mutation testing) dan permiso para mover piezas sin miedo.

Para que el juego sea justo, los pipelines miden y frenan: análisis estático, cobertura enfocada en cambios, umbrales de complejidad, convenciones de estilo, revisiones con linternas sobre legibilidad, feature flags y canaries para liberar sin sobresaltos, telemetría con logs estructurados, métricas y traces que cierran el loop de feedback. Así se transforma un campo minado en un tablero jugable y evolutivo.

¿Que prueba de luz roja detona primero en tu repositorio si hoy se detiene el juego?