Este artículo está basado en el
artículo de Martin Fowler “Is Design Dead?” y en su
traducción al castellano realizada por Alejandro Sierra.
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 SierraExamining the Agile Cost of Change Curve