Inicio
Blog
Contacto

Expansión adversa: Un problema de software

 29 Sep 2021 · Informática · Lectura de 3 min

Mantener un proyecto de software no es para nada una tarea fácil. Es bastante común encontrarse con una numerable cantidad de problemas en el camino, sobretodo en proyectos de gran envergadura, los problemas mas comunes van desde los conflictos de prioridades hasta la mala comunicación en el equipo de desarrollo, pero existe un problema que también es bastante común y hasta puede acabar con la vida de un proyecto, su única diferencia del resto de problemas es que este normalmente pasa desapercibido, y ese es, la expansión adversa.

La expansión adversa ocurre cuando el código fuente de un proyecto comienza a crecer a pasos agigantados mientras no se arregla la mala calidad del código existente. Entiendase que el proyecto puede empezar a crecer por múltiples razones, ya sea porque se le están añadiendo características nuevas o sencillamente porque se ha cambiado la estructura interna del código haciéndolo mas largo y complejo.

Wordpress es uno de los ejemplos más famosos de la expansión adversa, su código fuente es un espagueti gigante

La expansión adversa es bastante común, sobretodo en proyectos empresariales donde se manejan fechas limite y no se tiene el tiempo suficiente para solventar un problema o implementar una característica de la forma mas limpia posible, esto usualmente lleva a los desarrolladores a pensar que pueden dejar la mejora del codigo para el futuro y con ello tener tiempo para terminar y subir al entorno productivo el código funcional cuya calidad es cuestionable, lo que termina pasando es que el desarrollador se olvida de mejorar el codigo y el ciclo se repite, hasta que llega un punto en el cual, la mala calidad y alta complejidad del proyecto comienza atentar contra su propia integridad.

Tener un proyecto de software muy complejo o muy grande sin una verdadera necesidad es un dolor de cabeza, sobretodo por su manutención, es muy común encontrar en proyectos grandes cosas como comentarios sin sentido, algoritmos mal hechos u optimizados o código fuente que ya no se usa, todo este código basura y esta sobre-complejidad puede abrumar a los desarrolladores y dificultarles el crear características nuevas para el proyecto.

Un proyecto en el cual se ha tomado un buen tiempo para refactorizar su código y asegurar su calidad ayudara a salvar muchos dolores de cabeza a los futuros desarrolladores, incluso les puede ayudar a facilitar la implementación de cualquier funcionalidad nueva al tener una estructura limpia que sea fácil de leer y comprender.

Hay que recordar que normalmente mas de la mitad del tiempo se esta leyendo y no escribiendo código, es por eso que la calidad del código existente tendrá un gran peso en el tiempo y el nivel de dificultad de futuros desarrollos.

¿Cómo evitarlo?

La forma mas fácil de evitarla es asegurarse de que el código existente es de calidad y, en caso de no serlo, refactorizarlo antes de escribir cualquier código nuevo. En mi opinión, el tiempo que se dedica leyendo y arreglando código existente debería ser igual o mayor al tiempo que se dedica para desarrollar el nuevo código.

El refactorizar y mantener limpio un proyecto puede parecer algo ambiguo, así que explicare a que me refiero con eso: Siempre se tiene que apuntar a la sencillez, la solución a un problema debería ser simple indiferentemente de la complejidad del mismo (al menos en la mayoría de los casos).

También debería de evitarse el que haya un acoplamiento entre módulos, los módulos de un software deberían de estar bien abstraídos entre si, ya que si existe un modulo cuyo código es de pésima calidad o sencillamente no sirve, será mas fácil de refactorizar o de directamente eliminarlo y volverlo a implementar si esta bien abstraído del resto.

Otra recomendación es adherirse a un estándar, y por estándar me refiero a todo tipo de estándar, desde de identación hasta de estructuración, pero ¿cual estándar debería escoger? Pues ya eso queda a tu criterio, puedes escoger el que mas se ajuste a tus necesidades, recuerda que lo importante al final es estandarizar el código.