A todos aquellos interesados en el diseño de software les recomiendo que lean el paper Design Principles and Design Patterns, de Robert C. Martin (objectmentor.com). Sin embargo he querido hacer un pequeño abstracto de cuales son estos principios y su implicación en el diseño de software.
Empecemos con los sintomas que un mal diseño presenta y que es la principal causa para que un proyecto se vuelva caótico, inflexible y difícil de manter.
- Rigidez es el nivel de dificultad que tiene el software para ser modificado incluso en circunstancias o elementos relativamente sencillos; modificaciones que pueden estar estimadas para uno o dos días pueden volverse monstruos con los cuales lidiar durante semanas
- Fragilidad es la tendencia del software a quebrarse incluso en area conceptualmente no relacionadas. Como pueden imaginarse es bastante problemático tratar de mejorar una aplicación si cualquier cambio produce resultados inesperados
- Inmovilidad es la incapacidad del software para ser reutilizado. Imaginemos que tenemos un proyecto en el que nos gustaría reutilizar un componente que se encuentra en otro proyecto, o incluso en el proyecto actual, pero resulta que la dependencia que tiene este componente es tan grande que tratar de abstraerlo para ser reusable representa un coste mayor al de reconstruir el componente (ese no es un escenario muy agradable, cierto?)
- Viscosidad del diseño. Existen varias formas de modificar una aplicación, algunas preservan el diseño, otras lo arruinan - los conocidos hacks; ahora bien, si los métodos que permiten preservar el diseño son más complicados de implementar que los hacks estamos hablando de un diseño con una alta viscosidad
- Viscosidad del entorno es cuando el ambiente de desarrollo es lento e ineficiente, un buen ejemplo que el artículo nos entrega
Si el tiempo de compilación es excesivo, es probable que los desarrolladores realicen modificaciones que eviten esa pérdida de tiempo aunque eso implique dañar el diseño original e introducir falencias a la arquitectura de dicho software
Ahora bien, entre los principales motivos para que estas fallas se presenten podemos nombrar a la hoja de requerimientos; si consideramos que muchas veces los cambios son repentinos y que muchos de ellos deben ser hechos en corto tiempo podemos encontrarnos con la alternativa de realizar dichas modificaciones sin considerar sus repercusiones, lo que nos lleva a degradar el diseño del software e introducir problemas. Pero esto no es culpa de los requerimientos cambiantes - como desarrolladores, diseñadores y arquitectos de software sabemos que es uno de los documentos más volátiles que existen - es culpa de como diseñamos nuestro software.
Cada una de las causas mencionadas aparecen cuando existen dependencias inapropiadas entre los componentes del software, dependencias que afectan la posibilidad de mantener y mejorar nuestro software. Cómo evitar estas fallas? pues siguiendo ciertos principios de diseño… los cuales serán tratados en el próximo artículo ;o)