Páginas

viernes, 22 de octubre de 2010

Descomposición en el proyecto

Cuando se comienza el desarrollo de un nuevo proyecto de software lo ideal es tomar como punto de partida un diseño limpio, ordenado y elegante que, por norma general, nos debería llevar a desarrollar un código también limpio, ordenado y elegante. Todo está en su sitio y, al menos durante los primeros meses de vida, el proyecto se mantiene dentro de estos parámetros.

Pero en un momento dado, algo ocurre. Debido a demandas urgentes, a cambios funcionales, a la necesidad de resolver errores, o cualquier otra causa imaginable, empiezan a aparecer en el código pequeñas porciones de código sucio, enrevesado y/o poco elegante en forma de parches. Con el tiempo, estos parches, en principio pequeños y acotados, van apareciendo en cada vez más puntos del programa, hasta convertirse en la tónica habitual del código y convirtiendo, lo que en sus comienzos era un código limpio, ordenado y elegante, en una masa informe, el llamado código espagueti, que hace casi imposible el ampliar o mantener la vida del proyecto a lo largo del tiempo.

Llegados a este estadio, es bastante habitual ver a los equipos de trabajo realizar un esfuerzo para tratar de rediseñar el sistema, puesto que pequeños cambios en la funcionalidad que puedan ser requeridos por el cliente/usuario llevarán tras de si ingentes esfuerzos, y posiblemente tendrán como consecuencia efectos secundarios adversos (aparición de errores, peor rendimiento de la aplicación, ...).

Desgraciadamente, en muchos casos desde el mismo momento en que el equipo comienza a rediseñar el sistema comienzan a aparecer problemas puesto que para incorporar los cambios que se van aplicando al sistema en explotación se hace necesario incorporar diversos parches al nuevo diseño, antes incluso de que este se haga público, de modo que el día en que por fin puede entregarse, los propios diseñadores ya están valorando la necesidad de un nuevo rediseño del sistema.

El resultado final
la descomposición del proyecto.
Las consecuencias
impredecibles, aunque en general empeorarán en relación al tiempo que se mantenga el Proyecto en esta fase de muerto viviente.

¿Reconoces este proceso de descomposición de un proyecto? ¿Quien es/quienes son los responsables? ¿Crees que hay solución?

1 comentario:

  1. A eso se le llama deuda tecnica o technical debt como muy bien Martin Fowler explico aqui:

    http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

    Y si, se puede arreglar ;)

    ResponderEliminar