Cada vez que comenzamos un nuevo desarrollo, generalmente, podemos identificar una serie de tareas que son habituales y repetitivas.
Bien es cierto que, para algunas de estas tareas, son de utilidad las Software Factories, que no son más que un kit que sirve a arquitectos y desarrolladores como base para la implementación de buenas prácticas en el desarrollo de aplicaciones. Pero se quedán ahí, en la base.
El desarrollo de software moderno requiere algo más que una base..., requiere una estructura robusta, firme y estable que no sólo nos de la guía en inicio del desarrollo, sino que nos acompañe y nos obligue oriente durante todo el proceso de producción, siguiendo una metodología de base y unas buenas practicas.
Antes de continuar, quisiera aclarar, el significado de la palabra "Framework", que no es mas que una serie de funcionalidades, previamente diseñadas, que nos ayudan en el desarrollo convencional de software, este término puede dar lugar a confusión con Framework .NET, que como su propio nombre indica también es un Framework, ya que nos provee de una serie de funcionalidades preestablecidas.
Retomando el tema de las tareas habituales y repetitivas... en la mayoría de los desarrollos, nos vamos a encontrar, con la necesidad de hacer una conexión a datos, cargar grids, filtrarlos, hacer búsquedas, que dichos grids nos lleven al detalle del registro, eliminarlo, modificarlo o añadir un nuevo registro, sacar un informe, exportarlo a Excel, pdf, una gestión de excepciones, log de acciones, un cacheo de datos... además en todo desarrollo, vamos a tener que idear un sistema de seguridad basado en roles de acceso y permisos, un modelo de entidades que facilite el acceso a datos y lo haga independiente... ¡esto para empezar! ... pero también sería interesante que hubiese una capa de servicios, un generador de sentencias SQL, que todos los formularios siguiesen un patrón de diseño y comportamiento común dependiendo de los colores corporativos, que todas las aplicaciones estuvieran centralizadas, que compartir datos entre aplicaciones fuese fácil, etc...
Ahora imaginemos que diseñamos e implementamos una arquitectura que contempla todas estas ideas y todas las que se nos vayan ocurriendo, y que fuese un modelo extensible basado en interfaces, que con, simplemente, escribir una cadena de conexión, comenzásemos a tirar formularios al estilo "code and fix" ... "marchando un formulario tipo listado, que contenga las columnas de número de cliente, nombre, dirección y teléfono (click), la ficha asociada tendrá el resto de campos de la base de datos", (y fuese el Framework el encargado de gestionar las altas, bajas, modificaciones y seguridad de los registros) sería algo estupendo!! ... Al final tendríamos algo parecido a una churrera de formularios, uummm... Puesss que aburrido, ¿no?, ... ¡¡¡en absoluto!!! Porque todos nuestros esfuerzos se centraran, en primer lugar, en preparar la arquitectura y el modelo de datos y en segundo lugar, en enriquecer y realimentar el Framework con nueva funcionalidad y así incrementar la calidad.
http://www.youtube.com/watch?v=DI0Bdr9QKwA
¿Alguna duda? ¿Sí? vamos allá...
¿El coste?
Evidentemente el coste de diseñar e implementar una estructura de este tipo, es grande, pero a largo plazo, merece la pena. La calidad siempre se nota a largo plazo.
¿La productividad?
La productividad es muy alta, ya que no es necesario saber tanto .NET para hacer una aplicación, con centrarse en la capa de presentación, basta.
¿La estabilidad?
La estabilidad es el punto fuerte, ya que cuantas mas aplicaciones desarrolles con un framework, mas testado, robusto y evolucionado estará. Los bugs en producción tienden a cero y el rendimiento es alto.
¿La rentabilidad?
Una vez que el framework es estable y "la churrera" funciona a la perfección, podemos reducir el tiempo de desarrollo de forma considerable.
¿El usuario?
¡Encantado!, porque todos los formularios de sus aplicaciones tienen el botón de guardar y cerrar en el mismo sitio, con el mismo color.... en definitiva el comportamiento de sus aplicaciones es el mismo.
Por lo tanto, si incrementamos todos estos factores obtendremos un producto de mayor calidad y una estructura organizada para desarrollar nuestros proyectos.
Ahora cuento mi experiencia..., adjunto presentación por si alguien quiere más detalles (Presentación CIC Framework). Desde el punto de vista del desarrollador, el aprendizaje y la evolución fue muy satisfactoria y enriquecedora... sobre todo, el tener que pensar, que cada línea de código tiene que ser genérica para todas las aplicaciones y parametrizable mediante ficheros de configuración o de recursos, te obliga a ver las cosas desde otro punto de vista, te orienta el desarrollo a la reutilización y la modularidad (dos síntomas muy bueno de calidad), el dotar a esa estructura de inteligencia dependiendo del tipo de entorno... y con respecto a la rentabilidad, pues a medio plazo grande y ahora que el producto ya tiene madurez, muy grande.
Es obvio que cada uno de nosotros tenemos nuestras funciones de uso habitual (...), pero si toda esa funcionalidad la completásemos, organizásemos y la orquestásemos, para obtener una estructura que nos guie en nuestros desarrollos, seguro que obtendríamos mayor rendimiento y calidad en los mismos.
Lo que no cabe duda que una estructura de este tipo testada, estable, confiable, modularizable, parametrizable y ampliable nos aporta calidad a los desarrollos, por ello, y como es habitual, animo a las mentes inquietas, que todavía no lo han hecho, a diseñar y estructurar un Framework que aporte calidad sus desarrollos, que les ayude a ser más eficientes y no perder el tiempo en tareas rutinarias.