Seguimos desgranando los nutrientes de nuestro proceso de fabricación ecoLógica. En esta ocasión os desnudamos nuestras motivaciones, anhelos y logros en relación a su piedra angular: M.I.S.D.A.M … el Muy Ilustre Señor Don Apache Maven™ 😉 ( ciclo de vida con apache maven)

Como toda entidad con cierta historia -el 2004 suena ya antediluviano- en el área de Desarrollo SW del Sistema de Información Corporativo de Panel somos responsables del mantenimiento de múltiples aplicaciones Java, construidas en su día con el venerable Apache Ant™. Tanto en calidad de autores como de herederos, pero siempre como responsables.

Durante el último año hemos renovado de manera paulatina estas aplicaciones, migrándolas al musculoso Apache Maven™. Lo que podría parecer una mera evolución darwiniana entre descendientes responde, sin embargo, a motivaciones mayores.

Si Apache Ant™ permitía automatizar el proceso de construcción del software, Apache Maven™ automatiza el ciclo de vida del software. Queremos resaltar que no es algo complicado o confinante, antes que nadie se paralice maquinando si sus creadores pensaban en su día en cascadas o prototipos. Por desgracia, tampoco es que nos haga todo el trabajo a los desarrolladores.

El objetivo final es claro:
obtener resultados predecibles, de calidad contrastada y con el mínimo esfuerzo.
Económico y lógico, en suma.

Parte del «cómo» se nutre de esa automatización del ciclo de vida del software. Como tiene unas fases definidas y estandarizadas, hacer un mal uso de Apache Maven™ requiere más esfuerzo que lo contrario. De primero de Economía.

Sí, es cierto. Podemos saltarnos las pruebas, dando por bueno un código que lo único que tenemos seguro es que compila; podemos no compartir nuestro código nuevo, provocando que nuestros compañeros dediquen horas a algo que ya resolviste y duplicando código, en el menos malo de los casos, o podemos también no utilizar los repositorios comunes de librerías, gestionando «a pelo» las dependencias de todo el proyecto. Sin embargo, por contra, el tiempo requerido para gestionar correctamente todo esto mediante un archivo «.xml» es ínfimo.

Así, el tiempo necesario para desarrollar las pruebas, se compensa con el esfuerzo desproporcionado que se perdería arreglando incidencias de un código sin probar.

En todo caso, el ciclo de vida con Apache Maven  no es inamovible y ahí radica también parte de su potencial.  Con una arquitectura basada en complementos («plugins»), cualquiera puede desarrollar sus propias aplicaciones para implantar las fases que considere oportunas en su ciclo de vida o cambiar las predefinidas. En nuestro caso, nuestras predilecciones incluyen a SonarQube para poder realizar una inspección continua del código o Cargo ,para el despliegue de nuestras aplicaciones web en nuestros servidores. Existen una buena cantidad de complementos más, tanto de código abierto como privados, creados para dar acceso a conocidas aplicaciones comerciales.

¿Qué le exijo a todo ciclo de vida del software?
Que sirva para obtener software funcional y sostenible.
Que el propio proceso se enriquezca con el uso y la práctica.

Aunque las ventajas proporcionadas por Apache Maven™ son básicas para un verdadero desarrollo ecoLógico, podemos colapsarnos sin una correcta gestión de dependencias entre librerías, nuestras o de terceros. Es crítica.

Pudiera no parecer tan importante en comparación con el ciclo de vida, pero su ausencia nos supuso todo un escollo en el desarrollo y mantenimiento de nuestras aplicaciones.

El escenario no será desconocido para muchos desarrolladores:

• Múltiples proyectos utilizando decenas de librerías, muchas en común, algunas dispares, versiones diferentes y -todo- trabajando en paralelo.

Actualizar una librería es una aventura, y no para bien. Descubrir qué librerías adicionales hay que cambiar o incluso, en el peor de los casos, descubrir qué versión realmente es la que estamos utilizando. Si tu aplicación tiene una edad tendrás librerías de terceros en versiones descatalogadas o versiones antiguas de tus propios proyectos … mal identificadas y cuyo código se perdió en océanos de controles de versiones, tiempo atrás. Así, un buen día, el mantenimiento implica unos costes inviables.

La solución es conocida,
integrar una biblioteca de artefactos gestionados.

Su integración en el ciclo de vida tiene una clara recompensa, recuperamos la viabilidad perdida. En otra ocasión os presentaremos a nuestra pareja fantástica: Apache Maven y Nexus de Sonatype.

Recapitulando, lo importante no es el producto en sí mismo
(Apache Maven™ en nuestro caso),
sino los beneficios de un Ciclo de Vida saludable:
pautas aplicadas en la fabricación de código,
gestión eficiente de los recursos
y
reducción del tiempo en tareas repetitivas
pero necesarias para un desarrollo sano y libre de malas hierbas,
fruto de una deficiente gestión de nuestras librerías.

Pautas que, si el día de mañana debemos cambiar de herramienta, anhelaremos conservar.

Por último,  para llevar, nuestro decálogo para la fabricación ecoLógica de software:

• Mantén controlada tu deuda técnica, es posible que en el futuro no seas capaz de pagar los intereses que genera  – Responsabilidad.
• No improvises … sistemáticamente,  institucionaliza las reglas aplicadas a todos los proyectos – Institucionaliza.
• Descarga a las personas y a tu estación de trabajo de trabajos repetitivos – Automatiza.
• Aprende y aplica lo que aprendes – Conocimiento reutilizable.
• Cuida la maquinaria, te va la vida – Clinker by Klicap. 

————————