El conflicto entre la raíz de un problema y la estructura de datos que elegimos para resolverlo es un clásico en el desarrollo. Muchas veces confundimos el nivel base del sistema con la arquitectura que lo sostiene. Esta tensión genera discusiones acaloradas en los equipos, donde cada uno defiende su enfoque como si fuera la única verdad revelada.
La arquitectura como solución al desorden original 🏗️
Cuando el código se vuelve caótico, la tentación es reescribir desde cero. Pero la raíz del problema no siempre está en la base. Una estructura de datos bien definida puede resolver lo que parece un error fundamental. Por ejemplo, un árbol binario mal balanceado no se arregla cambiando la lógica de negocio, sino ajustando la forma de almacenar la información. El verdadero desafío es identificar si el fallo está en la raíz o en la estructura.
Cuando la raíz es un espagueti con patas 🍝
Todos hemos visto ese proyecto donde la raíz del sistema es un archivo de 5000 líneas con funciones que nadie se atreve a tocar. La estructura, por otro lado, es un Frankenstein de parches que intentan ocultar el desastre. Al final, el equipo prefiere echarle la culpa a la raíz antes que admitir que la estructura es un castillo de naipes. Y mientras tanto, el cliente pide añadir una funcionalidad que hará temblar los cimientos.