Me ha tocado en varias ocasiones enfrentarme al reto de definir el diseño técnico de una aplicación CRUD, es decir la típica aplicación de gestión de altas, bajas y modificaciones, con sus correspondientes listados. No es una tarea específicamente de arquitectura de desarrollo, pero dependiendo de la magnitud del desarrollo puede realizarse por la misma persona que define la arquitectura.
Normalmente estas aplicaciones las suelen construir programadores junior, que suelen agradecer que las cosas sean lo más sencillas posibles (En alguna ocasión ya he comentado este tema de Kiss).
Yo suelo utilizar una aproximación que me ha dado buenos resultados:
– Lo primero es ver que tipos de pantallas va a tener la aplicación y que hay de común en ellas. Normalmente suele ser la cabecera y pie, los tipos de paginas y la navegación entre ellas (página de filtro, luego página de resultado y paginas de mantenimiento), las opciones (añadir, guardar, borrar, modificar,…)
Esta es una tarea a realizar por un analista técnico o también por un arquitecto, aunque el arquitecto suele estar menos cerca del programador y se suele ocupar de temas más abstractos que el detalle de la programación.
– El siguiente paso es ver como se pueden mecanizar esos puntos comunes. Seguro que más de uno ha pensado inmediatamente en componentes reutilizables, en librerías de código, etc.
Literatura:
Si, esas cosas de código están bien, pero también hay que pensar en escribir un poquito. Recordemos que la aplicación probablemente la va a construir programadores junior, igual es hasta su primer trabajo, con lo que no tienen mucha experiencia y no queremos tener que estar constantemente con alguien al lado para explicarle las cosas o ayudarle, ya que eso implica incrementar las horas (la del ayudado y la del ayudante). Así que nos interesa que las cosas estén lo más sencillas posible.
Por mi experiencia personal el escribir en un pequeño documento o en una Wiki las reglas que se tienen que aplicar ayuda mucho a los programadores, porque son cosas que no tienen que pensar, ya se las das pensadas y además cuadriculadas. Bastante tienen con pensar el resto de cosas.
El plasmar en un documento cosas como, por ejemplo. Por cada mantenimiento va a haber 3 páginas que se van a nombrar de tal forma y se van a colocar en una carpeta con tal nombre. Cada página va a tener un clase de tal tipo para el código que se ejecuta en el servidor y con nombre tal y en la carpeta cual.
Como he comentado el disponer de este tipo de información facilita mucho el trabajo de los programadores más noveles, porque les centra, además de permitir que se puedan intercambiar programadores de un mantenimiento a otro.
Además disponer de este tipo de estructura de cara al cliente hace que incremente la confianza, ya que demuestra que por lo menos ha habido alguien que le ha dedicado algo de «seso» a pensar estas cosas y a homogeneizarlas, en contraposición a la anarquía del búscate la vida.
Código:
Si tenemos clara la estructura de los mantenimiento y los diferentes componentes (clases, jsp, etc) que hemos tratado anteriormente podemos empezar a pensar en pasar a codificar librerías y componentes.
Hay una cosa muy tonta que me ha dado muy buen resultado y es referida al tema de la presentación en pantalla, que normalmente requiere mucho esfuerzo para dejar a gusto del cliente.
Por ejemplo los botones. Si hemos definido que nuestra aplicación va a tener los botones, Añadir, guardar, borrar, etc, en vez de andar copiando todo el rato el mismo código, dando lugar a que cada uno lo llame de diferente manera, podemos hacer un pequeño componente para cada botón. De tal forma que siempre funcione igual y que además sea más sencillo el incorporarlo a la página, o modificarlo a posteriori si es necesario.
Hay una cosa que es importante tener clara, para automatizar primero hay que cuadricular y para cuadricular primero hay que pensar. No se puede automatizar el que cada uno haga las cosas a su modo. Bueno si se puede, pero es terrible. Lo digo por experiencia…