Podredumbre del software

Por Joaquin Gracia
Basado en un artículo de Robert C. Martin
22 de Agosto de 2004

¿Qué le pasa al software? El diseño de muchas aplicaciones comienza con una imagen clara en la mente del diseñador. En este estado el diseño es claro, conciso y elegante. Diseñadores y programadores desean verlo funcionar. Algunos de estos proyectos mantienen esta pureza de diseño hasta la primera versión.
Pero algo comienza a pasar. Al principio apenas es perceptible. Un parche por aquí, una ñapa por allá, aunque el diseño todavía mantiene la filosofía inicial. El software comienza a pudrirse. Las ñapas continúan y poco a poco el software se corrompe mas y mas hasta llegar un punto en el que afecta a toda la aplicación. El programa se convierte en una ingente masa de código que cada vez es más difícil de mantener. Entonces el esfuerzo requerido para hacer el más simple de los cambios es tal que los responsables de producto se plantean hacer un rediseño de la aplicación.
Los rediseños normalmente no fructifican. Aunque las intenciones de los diseñadores son buenas se dan cuenta de que es una tarea imposible. El sistema continua evolucionando, cambiando y el nuevo rediseño nunca termina. Un día la cantidad de problemas vuelve a ser tal que se los diseñadores lloran por otro rediseño.

Síntomas de un mal diseño

Hay cuatro indicios principales que nos indican que el software se esta pudriendo. No son independientes y están relacionados unos con otros, son: rigidez, fragilidad, inmovilidad y viscosidad.
Rigidez. Es la tendencia del software a ser difícil de cambiar, incluso en las cosas más sencillas. Cada cambio produce una cascada de cambios en módulos dependientes. Lo que parecía un cambio de dos días en un módulo resulta ser varias semanas de cambios de módulos tirando del hilo a través de la aplicación.
Cuando el software toma este camino, los gestores temen decir a los programadores que arreglen pequeños problemas que no son críticos. Esto ocurre porque ellos no saben con seguridad cuando acabaran los programadores. Todo el mundo hace "check-in" y nadie hace "check-out".
El miedo del gestor puede llegar a ser tan agudo que se niegue a realizar modificaciones en la aplicación. De manera que, lo que empezó siendo un diseño ineficiente acaba siendo una mala política de gestión.
Fragilidad. Muy relacionada con la rigidez está la fragilidad. La fragilidad es la tendencia que tiene el software a romperse por muchos sitios cada vez que se cambia algo. Muchas de las roturas ocurren en sitios que no están relacionados conceptualmente con el área que se está cambiando. Cada vez que los gestores autorizan un cambio tienen miedo de que el programa se rompa por algún lugar inesperado.
Conforme la fragilidad empeora, la probabilidad de que el software se rompa incrementa con el tiempo, acercándose cada vez más a 1. Este software es imposible de mantener. Cada arreglo lo hace peor, introduciendo más problemas de los que son solucionados.
Este software causa que los gestores y los clientes tengan la impresión de que los desarrolladores han perdido el control del software, perdiéndose así la credibilidad de los desarrolladores. Y frases como "Rompes más de lo que arreglas", comienzan a ser habituales.
Inmovilidad. La inmovilidad es la resistencia del software a ser reutilizado en otros proyectos o parte de otros proyectos. Pasa muchas veces que un programador descubre que necesita un módulo que es muy parecido a otro que ha desarrollado otro programador. Sin embargo, también pasa muchas veces que el módulo en cuestión depende demasiado de la aplicación en la que está integrado. Después de mucho trabajo los desarrolladores descubren que el trabajo necesario para separar las partes reutilizables de las partes no reutilizables es demasiado alto. Y entonces el software simplemente se rescribe en vez de ser reutilizado.
Viscosidad. La viscosidad de diseño es la dificultad de mantener la filosofía del diseño original. Cuando se afronta un cambio los programadores encuentran normalmente más de una manera de realizarlo. Algunas de estas formas preservan la filosofía del diseño y otras no. Cuando las formas de implementar el cambio preservando el diseño son más difíciles de realizar que las que no lo preservan, entonces la viscosidad del diseño es alta. Es fácil hacerlo mal y difícil hacerlo bien.
Estos cuatro síntomas son reveladores de un diseño de arquitectura pobre. Cualquier aplicación que muestra estos síntomas adolece de un diseño pobre.

¿Qué causa que el diseño se deteriore?

Requisitos cambiantes

La causa de la degradación del diseño es muy conocida. Los requisitos han ido cambiando de manera que no estaba previsto en el diseño inicial. A menudo los cambios necesitan hacerse rápidamente y hechos por programadores que no están familiarizados con el diseño original. Entonces, aunque los cambios funciona, violan el diseño original. Poco a poco los cambios continúan y las violaciones se acumulan hasta que el diseño se rompe.
Aún así no podemos echar la culpa a que los requisitos cambian y cruzarnos de brazos. Como desarrolladores, todos sabemos que los requisitos van a cambiar. Así que debemos realizar un diseño que soporte modificaciones sin que este pierda su consistencia.

Control de dependencias

¿Qué tipos de cambios hacen que un diseño se pudra? Los cambios que introducen nuevas e imprevistas dependencias. Cada una de las cuatro causas mencionadas anteriormente están relacionadas directa o indirectamente con dependencias entre módulos del software. Son las dependencias de la arquitectura lo que se degrada y con ellas el mantenimiento del software.
Para anticiparse a la degradación de las dependencias del diseño de la arquitectura, deben ser controladas las dependencias entre módulos de una aplicación. Este control consiste en la creación de "cortafuegos" de dependencias. A través de estos cortafuegos las dependencias no se propagan.
El diseño orientado a objetos esta repleto de principios y técnicas que nos permiten construir estos cortafuegos y controlar estas dependencias.
En posteriores artículos examinaremos estos principios y técnicas (patrones de diseño) que ayudan a controlar las dependencias de la arquitectura.