La verdad es que he descubierto en Martin Fowler una verdadera fuente de inspiración y de ideas sobre la ingeniería del software. En los últimos tiempos, basándome en sus artículos, estoy encontrando respuestas y reflexiones valiosas sobre los problemas que me afectan como desarrollador de software.
En este caso, llevo algún tiempo en conflicto entre la idea de realizar el diseño al principio del proyecto, paralizando todo desarrollo hasta tener una visión clara, o comenzar a desarrollar tan pronto como sea posible para tener algo que ofrecer como propugnan las metodologías ágiles, aunque esto implique rehacer lo ya hecho cuando las ideas se aclaran o varían.
En este artículo, Martin Fowler expone sus ideas sobre el diseño dentro de una metodología ágil como es XP que, aparentemente, no le da importancia.
Hay dos maneras de plantear el diseño, el diseño evolutivo y el diseño planeado:
- Durante el diseño evolutivo el diseño se realiza a medida que el sistema evoluciona, formando parte de la programación. Esta forma de diseño suele acabar en desastre porque termina siendo una agregación de decisiones puntuales que complican el código y deterioran el diseño.
- El diseño planeado se corresponde con la visión del diseño de cualquier ingeniería clásica, en donde se trata de anticipar los problemas de forma abstracta sin entrar en la codificación hasta haber terminado esta fase de diseño. Sin embargo, es difícil anticipar todos los problemas antes de comenzar con la programación, lo que hace aparecer tensiones entre programadores y diseñadores. También se pueden producir cambios en los requisitos que pueden deberse a cambios en el negocio y que, por tanto, son muy difíciles de preveer y de controlar sus efectos.
XP aboga por el diseño evolutivo. Sin embargo, para ello propugna una serie de prácticas que permiten controlar los efectos negativos de este tipo de diseño. Según la curva del cambio del software, el coste del cambio en programación aumenta exponencialmente a medida que avanza un proyecto, dificultando el diseño evolutivo. Pero esta curva se puede aplanar mediante una serie de prácticas que reducen el efecto de los cambios. Estas prácticas son:
- Pruebas: permiten controlar el efecto de los cambios eviatndo la introducción de nuevos errores.
- Integración continua: permite mantener el equipo en sincronía evitando que los cambios afecten a más gente.
- Refactorización: permite limpiar el código y hacerlo más mantenible y fácil de modificar.
En el diseño evolutivo XP dice que “hay que hacer la cosa más simple que pueda funcionar” y que no lleve a cabo todo aquello que no sea necesario (principio YAGNI – “You Ain’t Gonna Need It”). Se trata de mantener el diseño lo más simple posible haciendo sólo aquello estructamente necesario. Para ello existen dos razones:
- Si se hace algo que no es necesario ahora mismo se está comprometiendo el esfuerzo para quello que sí lo es. Además, se puede estar haciendo de forma incorrecta por falta de información, es mejor posponer su implementación hasta que se conozca con más detalle.
- Un diseño complicado es más difícil de comprender e implementar que uno sencillo. Haciendo lo estrictamente necasio se tiene un diseño más sencillo y fácil de implementar.
Sin embargo, esta forma de mantener el diseño simple añadiendo posteriormente lo que se vaya convirtiendo en necesario sólo es factible si se están usando las prácticas anteriormente descritas para reducir el costo del cambio.
Como pautas de le lo que es un diseño simple, Kent Beck expone los siguientes cuatro criterios:
- Correr todas la pruebas.
- Revelar toda la intención del código haciendo que sea fácil de leer.
- Evitar duplicación.
- El menor número de clases y métodos.
No es necesario perder demasiado tiempo buscando el diseño más simple. La refactorización permite irlo simplificando a medida que se va entendiendo. Tampoco es bueno usar patrones de diseño sin ton ni son, es mejor dejar que el diseño evolutivo te guíe hacia el uso de un patrón que introducirlo prematuramente.
Respecto al uso de diagramas y UML XP dice que se usen si son útiles, pero no es partidario de su uso. Los diagramas pueden ser útiles para la comunicación siempre y cuando se reduzcan a la mayor sencillez posible. Sin embargo, el uso de diagramas se complica cuando se producen cambios durante la evolución del proyecto, porque es difícil mantenerlos en sincronía con el código.
Algo importante en el diseño es evitar la irreversibilidad de las decisiones. De esta manera la toma de decisiones no es dramática porque las malas decisiones pueden ser deshechas. En este sentido es importante contar con sistemas de control del código que permitan garantizar la reversibilidad.
Es importante contar con gente involucrada en el diseño. Alguien debe ejecercer control sobre el proyecto vigilando el diseño del código y responsabilizándose de él. Estas personas deben actuar cuando se detecta que el diseño puede verse comprometido o hay alguna dificultad técnica durante el proyecto. Esta rol es el del líder técnico. No tiene sentido el rol de arquitecto, puesto que no puede existir el diseño por parte de alguien que luego se desentienda de la construcción del software.
El diseño de un proyecto se puede medir en función de la calidad del código base. Si la calidad del código base de un proyecto se deteriora y se vuelve más difícl trabajar, entonces el diseño es insuficiente. Éste es un criterio subjetivo, pero es la gente técnica la que primero sufre la dificultad de hacer cambios y a quienes se debe escuchar.
Según Martin Fowler, la naturaleza del sideño ha cambiado. Ahora se buscan las siguientes habilidades:
- Mantener el código tan claro y simple como sea posible.
- Ser capaz de refactorizar, haciendo mejoras en el diseño cuando sea necesario.
- Conocer y reconocer patrones y cuándo evolucinar hacia ellos.
- Saber comunicar el diseño mediante diagramas, código y comunicación directa con las demás personas.
Como resumen, Martin Fowler aboga por un diseño evolutivo que permita comenzar con el desarrollo de forma temprana. Pero esto no se puede hacer de cualquier manera, es necesario introducir prácticas que faciliten el cambio durante el desarrollo de forma que el diseño pueda mejorar y adaptarse a las nuevas necesidades que vayan apareciendo.
Esto va en contra de un diseño planeado que deja todo por sentado en un larga fase inicial y que es seguido por una fase de implemantación en que los cambios no se contemplan y que, cuando se incorporan porque terminan siendo absolutamente inevitables, son difíciles de incorporar, rompiendo el diseño previamente establecido e introduciendo una gran propensión a errores.
El diseño evolutivo delega gran cantidad de trabajo de diseño en los desarrolladores. No existe la figura de arquitecto como persona que realiza todo el trabajo de diseño, sino como alguien que supervisa el trabajo de estos. Se debe contar con un equipo capaz y comprometido para poder seguir esta forma de trabajo, de lo contrario, se hace inviable.
Referencias:
Is Desing Dead? - Por Martin Fowler
¿Ha muerto el diseño? - Traducción de Alejandro Sierra
Examining the Agile Cost of Change Curve
No conozco la metodología XP, y me queda una duda. El diseño como lo plantea este marco de trabajo, al ser simultaneo con la codificación, seria como la documentación de el código? o también es la base para la etapa de programación?
ResponderEliminarHola Jorges :-)
ResponderEliminarEn mi opinión la documentación de diseño, en una metodología àgil, se va desarrollando por iteraciones de la misma forma que se desarrollan el resto de entregables, por ejemplo un módulo de tu aplicación, la documentación de sistemas ....
Creo que la clave está en dejar de asociar el diseño a una única entrega de un único, y gran documento. Bajo mi punto de vista la documentación del código, las pruebas unitarias junto a la própia documentación de estas, los diagramas y documentos que pueden surgir a raiz de una reunión de "iteración", etc, componen la documentación de diseño. La premisa del desarrollo àgil "sin miedo al cambio" tambien aplica cuando hablamos de documentación. ¿Veremos algún día que la documentación de un proyecto se genera en una wiki (por decir algo) y que son los mismos usuarios (cliente), el departamento de sistemas y el equipo (en definitiva los máximos interesados de que el proyecto funcione bien y salga adelante) de desarrollo mantienen?
Por otro lado, tal y como comenté en el buzz no creo que el diseño esté muerto, vamos no lo cree ni el mismo Martin Fowler! Simplemente está cambiando la forma en la que se afronta un desarrollo de software. El artículo es de 2004 y yo ya siento que voy como 6 años (o más) por detrás de todo esto :-)
Siempre es interesante de releer y como siempre esperando poder aplicarlo (algún día) en la vida real.
Saludos
Un saludo
Hola,
ResponderEliminarPara los seguidores más radicales de la XP, la fase de diseño es la misma fase de codificación. No hay una etapa de diseño diferenciada cómo en otras metodologías como RUP.
En cambio, otros seguidores más moderados de las metodologías ágiles, como el propio Martin Fowler, ven en estas metodologías una alternativa al diseño completo inicial. Este diseño inicial es complicado y pocas veces estable. Con un diseño inicial más simple y una serie de prácticas que faciliten el cambio a posteriori (pruebas, integración continua, refactorización) se puede continuar o mejorar el diseño a medida que se avanza en el proyeco y se conoce mejor lo que realmente se quiere.
Estas metodologías tampoco son muy favorables a un diseño exhaustivo, con un modelo completo en UML y documentación extendida. Pero, en caso de ser necesario, como muy bien dice Edu, esta documentación pude elaborarse como un entregable dentro de una iteración si así es requerido.
¡Un saludo!