XML, esteroides anabolicos para nuestras aplicaciones

Vuelvo de mi trabajo y una idea ronda mi mente:

La programación declarativa con XMLs apesta y la inyección de dependencias se torna fácilmente en una pesadilla en un proyecto no muy bien documentado (alguien dijo scrum).
Tengo la sensación de que el uso de XMLs en el proyecto es similar al uso de esteroides anabólicos en los gimnasios. Crean gran masa muscular en nuestro aplicativo y cierta sensación de flexibilidad, pero definitivamente se llevan nuestra agilidad arrasando con el ciclo virtuoso del desarrollo. Nada mejor que salvar el archivo fuente que estamos editando y ver el cambio on the fly en el servidor.

Luego reflexiono unos momentos y pienso, pero tiene grandes ventajas:

• No genera acoplamiento entre componentes
• Facilita el testeo de componentes

Que no me gusta:

• No me gusta no poder cambiar lo configurado on the fly en forma simple
• No me gusta tener que redesplegar el aplicativo una y otra vez porque un xml de spring esta mal configurado.
• No me gusta bucear proyectos en eclipse buscando el binding de ese bean que explota al levantar el servidor de aplicaciones
• No me gusta no detectar problemas en dependencias al desarrollar en mi IDE.

Y no me digan que debería buscar en la documentación de proyecto, desde el mismo IDE debería ser posible determinar el camino de dependencia entre componentes.

Quizas es un problema de cultura, de no entender la escencia de la programación declarativa y resulta entonces que documentar la ubicación de los elementos de desacople (hoy por hoy defacto xml) es fundamental.

Porque nuestros IDEs no advierten la dependencia de estos archivos xml que ya no pueden ser vistos inocentemente como archivos de configuración ya que llevan consigo la responsabilidad del wiring de dependencias del aplicativo en su conjunto. Quizas cuando entendamos esto, que no son ya solo archivos de configuración y que deben ser considerado como código fuente, nos demos cuenta de la importancia de validar las dependencias presentes en los mismos y favorecer su rapida navegación en el IDE.

Y mas de lo mismo si tratamos el tema de Maven, nuevamente mas esteroides anabolicos XML al momento de compilar, empaquetar e instalar nuestro proyecto. Mas dependencias sin control y mas correr lentos comandos de compilación y empaquetado para ver un pequeño cambio en la clase que estamos modificando...

Cuanto tiempo perdemos realmente, bajando y subiendo nuestro servidor para probar cambios minúsculos.

J2EE evoluciona a un futuro muy lento de la mano de la programación declarativa que fuerza al redespliegue de las aplicaciones una y otra vez para probar cambios menores. Y al escribir esto no dejo de pensar ... y si todo fuera diferente... y si los lenguajes de scripting vinieran al rescate...

Naaa siempre tendriamos el dynamic binding para complicarnos la vida.