Hace ya un tiempo vi la siguiente imagen en internet, acerca de una experiencia
que casi cualquier programador ha vivido:
La verdad es una imagen que me arranco una sonrisa, y a la que francamente me he
enfrentado en multitud de ocasiones. Como antiguo programador de Visual Basic clásico
(anterior a Microsoft.NET), me he encontrado código con multitud de variables globales
sin tipo ( e incluso con más de un objetivo cada una), con funciones kilométricas
llenas de gotos, controles de errores extrañísimos, funciones altamente acopladas
o if encadenados hasta el infinito. Sistemas que fallaban si tosías cerca
demasiado fuerte. Recuerdo que bromeaba con que esas líneas no eran código fuente,
si no un conjuro escrito en una antigua lengua olvida, que levantaba el sistema.
El caso es que un software vale tanto como tan mantenible puede llevar a ser. Un
sistema no es un edificio que pueda estar levantado inmutable durante siglos, es
un ente que debe evolucionar para ajustarse a las mismos cambios por los que pasa
el mercado, el dominio que intenta abarcar nuestro sistema, lo que llamamos
habitualmente el negocio. De esto hemos hablado aquí y aquí.
Es obvio que de forma inconsciente y progresiva todos queremos cierta estabilidad
en el negocio que estábamos implementando, y cuando mas tiempos hemos estado
involucrados en dicho negocio (sobre todo si es de una forma pasiva), menos
vamos a querer que cambie, incluso podemos, sin darnos cuenta, sabotear el cambio.
Esto se llama zona de confort. Sin embargo, basta con dar un vistazo al mismo
mercado de nuestra profesión para darnos cuenta que el cambios es algo inevitable,
veamos cómo ha cambiado la informática desde los 90 hasta ahora, o la telefonía
móvil desde hace una década. los cambios son cada vez mayores y mas rápidos, los
sistemas que antes duraban décadas, pasaron a durar años y en la actualidad tenemos
sistemas que reciben actualizaciones cada pocas semanas o incluso a diario. Es inútil
negar la necesidad de cambio y adaptación que tiene los sistemas actuales, hacerlo
es condenar a nuestro negocio a quedarse obsoleto en el mercado y finalmente a desaparecer.
Lo cual nos lleva a la imagen que acompaña al post, imaginemos que es una situación
real, estaría impidiendo a nuestro sistema poder adaptarse a nuevas necesidades,
dejándolo atrapado estáticamente en la misma funcionalidad.
Pensando en cómo se ha llegado a esa situación, posiblemente sea por alguno (o todos)
de los siguientes problemas y errores:
-
Es una función terriblemente grande, con muchos caminos y ramificaciones, tal que no puede ser comprendida en su totalidad.
-
La función hace más de una cosa
-
La función usa, y modifica, variables globales.
-
La función necesita ser llamada en determinada secuencia junto con otras.
En resumen la función esta acoplada fuertemente dentro del sistema, de forma que
no puede ser considera una parte independiente, extraíble o sustituye. Es un "todo"
junto con el resto de funciones.
En esta situación es una bomba de tiempo esperando explotar en cualquier momento,
es necesario ser consciente de la situación y ponerle remedio, analizar las dependencias
de la función o el modulo oportunamente y reestructurarlo para que el sistema sea
libre de poder recibir nuevos cambios y funcionalidades con el menor impacto posible.
