Hay una pregunta muy clara que diferencia la mentalidad de un programador que solo busca que algo funcione de uno que diseña software para que dure:
Si dentro de seis meses tengo que cambiar este módulo o la lógica de negocio evoluciona, ¿cuántos archivos voy a tener que romper?
Cuando estás empezando, la prioridad es que la pantalla pinte el dato, que el test pase en verde y cerrar la tarea antes de que termine la jornada. Pero a medida que avanzas como programador y buscas dirigir tu carrera hacia un perfil Senior, te das cuenta de que hacer que el código funcione es la parte fácil.
Lo verdaderamente difícil es hacer que siga funcionando cuando el proyecto cambia.
Y para lograrlo solo hay una vía: dominar el arte del desacoplamiento.
Hoy, en de CERO a SENIOR, quiero explicarte cómo evitar la trampa del código frágil y por qué, en plena era de la Inteligencia Artificial, este concepto de arquitectura es la mayor ventaja competitiva que vas a tener en tu carrera.
La trampa del acoplamiento y el código de cristal
El acoplamiento es un síntoma de código de mala calidad y que empezamos a observar en nuestro código cuando vemos que dos o más componentes de un sistema están tan entrelazados que cambiar uno te obliga a rastrear y modificar diez partes distintas.
Creo que todos hemos tenido ese típico dolor de cabeza que nos empieza a dar cuando vemos que al modificar X parte del código, hay otras que empiezan a fallar por arte de magia.
Y es que si no te esfuerzas conscientemente por escribir código flexible, acabas construyendo un código de cristal, ese código que funciona perfectamente mientras nadie lo toque, pero al menor cambio, salta por los aires en producción de la forma más insospechada.
Sí, ese código que todos queremos evitar pero que antes o después, hemos terminado escribiendo desde nuestra inexperiencia.
Pero no te preocupes, que para evitar esto, te voy a contar una regla fundamental que empecé a aplicar y me ayudó mucho: la de separar las cosas que cambian por razones distintas.
Dicho así suena muy sencillo, pero en el día a día es donde la mayoría fallamos.
Mezclamos la lógica que calcula un descuento con la consulta a la base de datos que trae al cliente, y de paso con el formato en el que vamos a enviar el correo de confirmación. Todo en la misma función o en la misma clase.
El problema de hacer esto es que cuando el departamento de marketing decide cambiar las reglas del descuento, terminas tocando sin querer la parte que envía los correos, y ahí es donde aparece el desastre. Separar por razones de cambio significa que si cambia la forma de cobrar, toques el módulo de cobros; y si cambia el diseño de la factura, toques el módulo de plantillas.
Ni más, ni menos.
Para poder aplicar esta regla con éxito, lo primero que tuve que hacer fue aprender a detectar las trampas en las que caía continuamente sin darme cuenta. Esos vicios de diseño que parecen inofensivos cuando estás picando código, pero que en realidad están atando tu aplicación de pies y manos.
Hay tres escenarios en concreto que son auténticas fábricas de acoplamiento y a los que deberías empezar a poner la lupa:
1. Los Train Wrecks y la Ley de Demeter
¿Has visto alguna vez una cadena de llamadas a métodos que parece una vía de tren sin fin? Algo como esto:
$user->getOrders()->last()->getInvoice()->getPaymentMethod()->process();A simple vista, cuando estás empezando, te puede parecer código limpio, compacto e incluso elegante. La realidad es que es un choque de trenes en toda regla y una bomba de tiempo en tu repositorio.
El problema de esa línea no es solo que si el último pedido no existe la aplicación salta por los aires. El problema real es que ese módulo necesita conocer la estructura interna de cuatro clases diferentes para ejecutar una simple acción. Tu código “sabe demasiado” sobre cómo están hechas las cosas por dentro en otros sitios. Si mañana el equipo decide cambiar la forma en que se estructuran las facturas, esta línea se rompe. Y la que está en aquel otro controlador, también.
Para solucionar esto existe la Ley de Demeter, que a mí me gusta resumir como el principio del mínimo conocimiento: habla solo con tus amigos directos, nunca con los amigos de tus amigos.
Tu código solo debería conocer a sus dependencias inmediatas. Si necesitas procesar algo del usuario, pídeselo al objeto User o a un servicio de pagos dedicado, pero jamás fuerces a tu capa superior a navegar por toda la arquitectura para conseguir un dato.
2. Los males de la globalización y lo estático
El estado global es probablemente la fuente más traicionera de acoplamiento que existe en el desarrollo de software.
Variables globales, Singletons usados sin control o llamadas a métodos estáticos que leen la base de datos o la configuración en cualquier rincón de tu aplicación crean hilos invisibles por todo el proyecto.
Son como cables pelados que cruzan la pared sin que nadie los vea.
Este tipo de código provoca que probar un módulo de forma aislada —hacer un simple unit test— se convierta en un infierno, porque el comportamiento de lo que estás probando depende mágicamente de lo que haya hecho otro componente cinco minutos antes en otro lugar de la memoria.
Cuando buscas un código más profesional y con mejor arquitectura te das cuenta de que la inyección de dependencias no es simplemente tener ganas de escribir más código: es la forma de hacer que cada pieza sea autónoma y transparente.
Si una clase necesita algo para funcionar, pídeselo en el constructor. No dejes que salga a buscarlo a ciegas al ámbito global.
3. El peligro oculto de la herencia
Durante muchos años, en la universidad o en los cursos de programación, nos vendieron la herencia como el pilar absoluto de la Programación Orientada a Objetos. Te enseñaban el típico ejemplo del Animal y el Perro y todo parecía encajar perfectamente.
La realidad en proyectos de negocio reales es muy distinta: la herencia añade un acoplamiento feroz.
Cuando creas una subclase que hereda de una clase base, esa subclase queda encadenada para siempre a los detalles de implementación de su padre.
Cualquier modificación que hagas en la clase base para solucionar un problema concreto puede romper inesperadamente el comportamiento de tres o cuatro subclases que ni recordabas que existían en otra parte del sistema.
Pero… ¿cómo solucionamos esto?
Pues priorizando casi siempre la composición sobre la herencia.
No hagas que tu clase sea algo, haz que tu clase tenga algo. Modulas mejor, reduces el impacto de los cambios y ganas una flexibilidad brutal cuando las reglas de negocio evolucionan.
Por qué la IA te está preparando un campo de minas
No puedo hablar de arquitectura hoy sin mencionar lo que está pasando en nuestro día a día con la Inteligencia Artificial porque estamos viviendo un momento en el que generar código es ridículamente fácil y rápido.
Le pides a un LLM una función, te devuelve la respuesta en tres segundos, la pegas, ves que funciona y sigues a la siguiente tarea. Es la era del vibecoding.
Pero aquí está el verdadero peligro para tu carrera si quieres construir software serio: la IA tiende de forma natural al acoplamiento.
Los modelos de lenguaje están optimizados para darte la solución más rápida, directa y funcional al problema concreto que le acabas de plantear en el prompt.
La IA no se va a parar a pensar de forma espontánea en la arquitectura global de tu proyecto a tres años vista.
- Te creará funciones que invocan directamente métodos estáticos para ahorrar líneas de código.
- Te sugerirá herencias profundas porque es el camino más obvio para resolver el caso puntual.
- Acoplará la capa de presentación o las vistas directamente con la base de datos sin despeinarse.
Si utilizas estas herramientas sin tener estos conceptos de arquitectura grabados a fuego en tu cabeza, te vas a convertir en un mero copiloto que valida código que parece correcto hoy, pero que está dejando una deuda técnica devastadora para mañana.
Las aplicaciones “vibecodeadas” sin supervisión arquitectónica van a ser el código heredado más difícil e infame de mantener de los próximos años.
La IA es un motor de velocidad increíble para ejecutar, pero la responsabilidad del diseño y de la salud del sistema sigue siendo, nos guste o no, 100% tuya.
Escribir código para humanos
Escribir código desacoplado requiere más esfuerzo inicial, no te voy a engañar. Requiere frenar el impulso de picar a lo loco, tomarte un café y pensar un par de minutos antes de crear una clase o definir un módulo.
Cualquier programador, incluso con poca experiencia o ayudado por una IA, puede escribir código que una máquina entienda y ejecute. Sin embargo, lo que define a un verdadero Senior es la capacidad de escribir código que los humanos puedan entender, mantener y evolucionar con el paso del tiempo sin sufrir en el proceso.
La próxima vez que vayas a cerrar un pull request o a dar por buena una funcionalidad, hazte la pregunta con la que empezamos hoy:
Si esto cambia mañana, ¿cuántas cosas voy a romper?
Si la respuesta es una sola, vas por el buen camino.
Nos leemos en la siguiente entrega,
Julián.