Para quienes trabajamos en el diseño y desarrollo de software no resulta ajena la imagen de aplicaciones de retorcidas entrañas en las que realizar cualquier cambio mínimo en su código fuente supone un arriesgado ejercicio además de una tortura. Sin embargo, no siempre fue así. Al principio, cuando la aplicación estaba aún en la mente de sus diseñadores, su estructura era simple y elegante. Los programadores la imaginaron eficiente y eficazmente descrita por líneas de código limpias y estructuradas. Pero algo cambió y esa aplicación primigenia e ideal tornó en un monstruo de difícil trato y desagradable aspecto. ¿Qué había ocurrido?
Resulta demasiado habitual que el software pensado por los diseñadores no sea en su totalidad el que imaginaron los clientes, o estos se den cuenta a posteriori de que no cumple con todo lo que esperaban de él. Esto lleva a continuos cambios en los requisitos existentes y a la aparición de otros no previstos originariamente que se ven plasmados en diversos cambios realizados sobre la marcha que, de no ser bien gestionados (en muchas ocasiones se llevan a cabo en plazos de tiempo reducidos, a veces por desarrolladores que no están familiarizados con el diseño original…), dan como resultado un código fuente difícil de entender, modificar y, por tanto, de mantener a largo plazo.
 |
| Dos aguerridos programadores se disponen a realizar un cambio en el software preexistente. |
- Rigidez o, como personalmente me gusta llamarlo, “el hilo de Ariadna”: es la oposición del software al cambio y se hace evidente cuando hasta la más pequeña modificación del mismo requiere de un esfuerzo y tiempo superiores a los que cualquiera habría sido capaz de estimar. Lo llamo el “hilo de Ariadna” porque empiezas a tirar del hilo, que parece corto, y terminas metido en el laberinto del Minotauro. El desarrollador verá que está ante software excesivamente rígido si, cuando tiene que realizar un cambio, se ve obligado a realizar, en cascada, muchas más modificaciones de las que había previsto.
- Fragilidad: está muy relacionada con la anterior, ya que un cambio puede tener repercusiones sobre otras funcionalidades de la aplicación y, dando solución a un problema llegamos a provocar otro incluso mayor en cualquier lugar inesperado. Esto puede llevar a que se produzcan numerosos errores durante el proceso de cambio y a que los clientes tengan la sensación de que el equipo de desarrollo tiene escaso control sobre su propia creación.
- Inmovilidad: supone la dificultad o imposibilidad de reutilizar el código entre distintos proyectos. Se manifiesta cuando un desarrollador sabe que un determinado módulo podría ser usado en una nueva aplicación por llevar a cabo una función similar a la que realiza en la original pero al intentar usarlo se encuentra con que tiene demasiadas dependencias con la aplicación en la que se encuentra integrado.
- Viscosidad: cuando un desarrollador necesita realizar un cambio en el software en ocasiones encuentra varias formas de implementarlo. Unas serán más respetuosas con el diseño original, manteniendo la arquitectura de la aplicación y otras serán más agresivas, incrementando la complejidad del software y “pudriéndolo” aún más. Este síntoma se manifiesta cuando para el desarrollador resulta más sencillo realizar el cambio con una de las implementaciones que rompen el diseño que con una que lo preserve.
- Una complejidad innecesaria: Aunque los diseñadores y desarrolladores deben tener en mente que se producirán cambios futuros en el software, bien por cambios en los requerimientos, bien por tener que incorporar nuevas funcionalidades, y por esto mismo deberían de huir de la rigidez haciéndolo más flexible, lo cierto es que esto puede llevar a imprimirle una complejidad que no se corresponda con lo exigible al mismo: el sistema habrá sido sobredimensionado (“sobrediseñado”, por decirlo de algún modo) y presentará una infraestructura que habrá implicado un costo sin que vayan a obtenerse beneficios de ella.
- Una repetición innecesaria: ¿cuántas veces habrá loado un desarrollador a Larry Tesler, creador del “copiar y pegar”? Mas, ¿cuántas otras habrá maldito esta operación cuando se ha encontrado con bloques de código repetidos en la aplicación con la que está trabajando, viéndose obligado a rehacer el código o, manifestando los síntomas de rigidez y viscosidad, replicando una y otra vez el cambio mínimo que se ha visto obligado a hacer en diversas partes del programa? El código duplicado debería unificarse y ofrecerse bajo una única abstracción. Esto facilitará que el software no se manifieste excesivamente inmóvil.
- Opacidad: el código fuente se manifiesta “opaco” cuando no puede leerse e interpretarse con claridad, sino que aparece desorganizado, con líneas de código comentadas, ya obsoletas y sin uso, “código espagueti” ante el cual una sentencia goto nos parecería encomiable y que crea en el desarrollador la sensación de no terminar de entender qué hace el programa. Escribimos el código para que pueda ser leído y entendido (por otros y por nosotros mismos).
Si nos fijamos, según lo expuesto una de las características del software que puede llevarlo a un estado de indeseable putridez es la existencia de dependencias entre los módulos que lo componen. Podremos lidiar de forma más eficaz con los imprevistos si seguimos unos principios básicos en el diseño de nuestras aplicaciones orientadas a objetos. Ya que existen artículos más que completos e interesantes sobre el tema, os animo a profundizar en el tema siguiendo, por ejemplo, la serie que The Art of Left Foot dedica al mismo,
- Principios básicos de orientación a objetos.
- Principios de S.O.L.I.D.:
además de leer el inspirador y completo artículo de Robert C. Martin, Design Principles and Design Patterns, sin perder de vista el trabajo sobre los principios de S.O.L.I.D. recogidos por Robert "Tio Bob" Martin en su página web bajo el título The principles of OOD.
No hay comentarios:
Publicar un comentario