¿Qué guía tu desarrollo?

23-01-2006 Luis Artola

Sabemos que, al final, tu sistema será un conjunto de clases que representa la lógica de presentación(vistas más navegación), otro conjunto con la lógica de negocio (modelo de dominio, capa de persistencia) y otro conjunto con los test unitarios que validan el código escrito en los otros dos conjuntos.

Sabemos que al final será así. ¿pero y al principio? Basándonos en los postulados del desarrollo ágil, el software es impredecible. Un programador no puede especificar totalmente un sistema antes de programarlo. Si esto es cierto, necesitaremos una manera de “guiar” nuestro desarrollo de forma que vayamos descubriendo los requisitos funcionales del sistema y el código que lo representa. La clave está en ir implementando el código a la vez que se va diseñando, tratando de minimizar la cantidad de código que luego haya que echar a la basura (luego, cuando hayas descubierto más sobre el sistema).

Algunas formas básicas de descubrir nuestro codigo son:

1. Test Driven Development: es la manera que sigue la Programación Extrema (XP). La idea es crear el test unitario de una clase antes que la propia clase y así ir descubriendo los requisitos que deberá cumplir. ¡Ojo!: si primero creas la clase y luego el test unitario, entonces no estás guiando tu desarrollo por el test.
2. Model Driven Development: la idea es centrar el esfuerzo en el desarrollo de la lógica de negocio. El diagrama del Modelo de Dominio representa a todas aquellas clases que implementan la lógica de negocio. Mientras implementas clases que representan lógica de negocio descubres nuevas necesidades del sistema que serán representadas por nuevas clases relacionadas de una u otra manera.
3. Template driven development: es la que utilizo yo. La he llamado así por ser un poco pedante. Realmente todo se reduce a implementar la capa de presentación antes de implementar la lógica de negocio y así ir descubriendo qué llamadas a la lógica de negocio necesitará el sistema viendo qué datos necesitamos sacar en la presentación y qué acciones necesitaremos realizar. ¿ventajas? Mientras descubrimos la lógica de negocio a través de la implementación de la capa de presentación, creamos un prototipo mostrable al cliente para que nos diga si es correcto o no (feedback). Además podremos ir trabajando aspectos importantes como el esquema de color, apariencia general de la página y hoja de estilos. También tiene la ventaja de no implementar ninguna lógica de negocio que el cliente no haya validado primero.

Evidentemente para poder aplicar estas diferentes aproximaciones al desarrollo de software hay que utilizar diferentes técnicas (patrones, etc.) que te permitan separar la lógica de presentación (navegación y vistas) de la lógica de negocio (Modelo de dominio, capa de persistencia, …) así como un framework de testeo unitario (jUnit, phpUnit, …). Estas prácticas están ampliamente extendidas y son muy recomendables.