Aquí comienzo mi camino en este blog, agradeciendo en primer lugar a Plain Concepts y en especial a Rodrigo Corral, por esta oportunidad de expresión en esta gran plataforma de referencia para buena parte del mundo .Net en castellano.

Sobre qué intentarán aportar mis artículos ya adelanta algo el título de éste. En primer lugar, intentaré dar una visión un poco más cercana de cómo aprovechar las múltiples posibilidades que nos brinda Visual Studio 2010 para ser extendido con nuestros "plugins". La irrupción de los paquetes VSIX, la adopción de MEF y la explosión de Visual Studio Gallery como repositorio de extensiones, nos demuestran la fuerte apuesta de Microsoft, ahora más que nunca, por  lograr que Visual Studio sea realmente una plataforma de desarrollo fácilmente extensible.

Esta primera línea temática navegará sobre otra, un poco más profunda y que me han inculcado desde que comencé con esto profesionalmente, y es la de tendencias o metodologías como Software Factories, desarrollo dirigido por modelos, líneas de productos, generación de código, etc. En definitiva, exprimir hasta la última gota de productividad de nuestras herramientas de desarrollo.

Soy consciente de que hay mucha corriente en contra. Mucha gente que prefiere los matices de Software Craftmanship y similares, y que reusa de cualquier cosa que le impida escribir hasta el último punto y coma de su código. No obstante, mis ideas no son caprichosas. No son fruto de la teoría, sino del pragmatismo más extremo. Vivimos de servicios de software en Andalucía, sin inversores, sin padrinos políticos ni aliados poderosos. Es un escenario maravilloso para la evolución, y ella es la que nos ha puesto estas ideas en nuestras cabezas. Claro que nos encantaría poder escribir código como el que pinta un cuadro, y disfrutar una a una de cada una de nuestras obras y cuidar cada uno de sus detalles. Pero no podemos. Simplemente es fruto de la pura supervivencia.

Actualmente trabajo en un proyecto que me ilusiona bastante y del que creo que podré comentar cosas interesantes relacionadas con las líneas que comento. Se trata del desarrollo de una herramienta en la onda de Data Dynamics y WCF RIA Services pero que busca rellenar el hueco de semántica, flexibilidad y extensibilidad que éstas no cubren. El por qué no poder usar los conceptos de alta productividad de estas herramientas en proyectos que requieren de bases arquitectónicas mucho más sólidas fue lo que nos empujó a materializar esta iniciativa.

A grandes rasgos, intentamos converger varias tecnologías Microsoft como plantillas de proyecto para definir arquitecturas, plantillas T4 para definir artefactos, y DSL Tools para definir modelos, para dar lugar a una plataforma de desarrollo dirigido por modelos siguiendo las líneas que marcaron Greenfield y Short en su libro Software Factories (http://www.softwarefactories.com/TheBook.html). Recientemente, y como prueba de fuego, usamos la arquitectura que están desarrollando César de la Torre y Unai Zorrilla, entre otros, (http://microsoftnlayerapp.codeplex.com/) basada en la que propone Eric Evans en su libro “Domain Driven Design” (http://domaindrivendesign.org/books). Si queréis ver algún vídeo de los resultados, sólo tenéis que pedírmelo.

Entiendo que quizás pueda chocar un poco la dualidad de DDD’s: una arquitectura surgida de Domain Driven Design con este tipo de herramientas más afines al Data Driven Development. Sin embargo, encontramos varios escenarios en los que la aleación de matices de ambos paradigmas puede ser satisfactoria.

Detectamos, por ejemplo, clientes en estados de baja madurez tecnológica que, pese a que concentran procesos de negocio relativamente complejos o cambiantes, no tienen capacidad financiera, o consideran demasiado costoso y prescindible emprender una solución acorde a sus necesidades. Una solución que conllevaría, si somos partidarios de Eric Evans, un proceso de desarrollo inmerso en un lenguaje ubicuo, que resultara en una capa de dominio que plasme fielmente los procesos del negocio. Todo ello sobre una arquitectura que permita que el negocio evolucione sin interferencias tecnológicas de ningún tipo, entre otras cosas. Obviamente todo esto tiene un coste.

Normalmente el contraste de intereses entre ambas partes hace inviable el proyecto. Una solución intermedia que se puede aportar es usar herramientas de alta productividad  tipo RAD (como las que antes comenté) para crear un producto intermedio, no demasiado ambicioso, que pueda despertar el interés tecnológico del cliente, y con el que pueda medir fielmente el aumento de productividad que le supone con respecto a, por ejemplo, las herramientas de ofimática. Sin embargo, es evidente que hay un lado oscuro en este tipo de soluciones.

El bajo grado de madurez de este tipo de clientes implica procesos de negocio muy cambiantes. A su vez, la base arquitectónica del producto desarrollado con herramientas RAD no es adecuada para entornos con alto nivel de complejidad  y/o cambio. Esto hace que, si bien solemos conseguir despertar el interés en el cliente por desarrollarse tecnológicamente, nos volvemos a enfrentar a un conflicto de intereses. Conflicto que viene dado porque el cliente no suele asumir los altos costes de una refactorización completa del producto, desde el nivel arquitectónico, lo cual resulta imprescindible para mantener el evolutivo junto al aumento de interés por seguir perfeccionándolo.

Es aquí donde creo que una herramienta que ponga unas bases arquitectónicas sólidas, con los parámetros de alta productividad de las herramientas RAD puede ser óptima. No obstante, hay otros escenarios que se encuentran mucho más exhaustivamente estudiados en los que también pueden ser eficientes estas herramientas, como líneas de productos en dominios verticales, prototipado real rápido, normalización de desarrollos en factorías, etc.

Por último, siguiendo una línea metodológica parecida que además aprovecha las nuevas oportunidades que nos ofrece el Cloud Computing, me encuentro enfrascado en otro proyecto bastante innovador, sobre el que espero escribir algún artículo. Se trata de usar la plataforma Windows Azure para aprovechar su poder de paralelización en la generación de código. De este modo se pueden construir servidores de generación de modo que el cliente modele en local y use Azure para generar los artefactos correspondientes, totalmente en paralelo. El proyecto aún está en fases tempranas de desarrollo, sin embargo, ya hemos encontrado bastantes temas interesantes que iré relatando a medida que vaya teniendo tiempo.

Y poco más, ya sólo queda ponerse manos a la obra. Al lío!!