Frameworks Ágiles en la Plataforma JEE
Por: Ing. José Amadeo Martin Díaz Díaz
E-mail: [email protected]
Twitter: @jamdiazdiaz
Web: www.joedayz.pe
No soy mucho de escribir
artículos, así que espero realmente que pueda transmitir adecuadamente el
mensaje sobre los Frameworks Ágiles para la plataforma JEE.
En mis 12 años de experiencia
profesional he sido analista programador, arquitecto, coordinador y Gerente en
diversos proyectos para la plataforma JEE.
Utilizo el lenguaje Java desde que salí de la universidad la PUCP (1).
Si bien Java no se caracteriza por
ser un lenguaje dinámico, sino más bien verboso y lleno de clases e interfaces
que aprender, es hoy por hoy el lenguaje escogido por muchas organizaciones
gubernamentales y privadas. “Al cesar lo que es del cesar”.
Sumado a esto tenemos diversos
IDEs o entornos de desarrollo (NetBeans (2), Eclipse (3), Intellij Idea (4)),
Contenedores de Servlets (Ahí tenemos al popular Tomcat (5)), Servidores de
Aplicaciones para escoger (JBoss (6), WebSphere (7), GlassFish (8), WebLogic
(9), tc-server (10), etc), APIs,
Middlewares, Enterprise Server Bus (Mule (11), Apache Service Mix (12)),
Messaging como Rabbit MQ (13), Frameworks de persistencia (Hibernate (14),
Mybatis (15), JPA (16)), Frameworks Web (Spring MVC (17), Tapestry (18),
wickets (19), struts 2 (20), JSF 2.0 (21)), y podemos seguir nombrando más
categorías ubicadas en el segmento open source y/o comercial.
En definitiva hay muchos caminos
que seguir, y supuestamente las empresas que deberían apoyarnos Oracle (22),
IBM (23), RedHat (24) y ahora VMWare (25) en su mayor parte no se destacan por
innovar, casi la mayoría de estándares que tenemos hoy vienen de iniciativas
open source. Gracias a Hibernate y Spring podemos para “muestra un botón” dar
como resultado el estándar compuesto por EJB 3 (26) y JPA.
El camino que esperamos no es
difícil de pensar o desear. Ellos deberían seguir las actividades más
productivas y eso volverlo estándar. No sacar un estándar que finalmente solo una
muestra de la comunidad Java utiliza.
“Otro botón” el muy conocido Java Server Faces. Que hoy por hoy aún no es adoptado en todas
las organizaciones y se utiliza más en ambiente intranet y por evitar la
complejidad del modelo request – response.
Los años pasan y no solo las
metodologías están pidiendo cambios. Por muchos años hemos llevado proyectos siguiendo
los lineamientos de RUP (27), PMI (28) y hemos seguido el esquema Análisis,
Diseño, Construcción, Implantación, Soporte Post Implantación. Este modelo que
suena a “Cascada” (29) funciona muy bien para proyectos predecibles, similares,
pero, para crear nuevos productos o para proyectos de mucho tiempo puede
convertirse en una relación en el que ni el cliente ni el proveedor al final se
quieren ver. Creo que esto es entendible. ¿Quiénes fueron nuestros primeros
profesores de software?, pues Ingenieros Civiles e Industriales. Ellos pues
siguen dicho proceso. Nosotros necesitamos algo diferente.
Las metodologías ágiles entonces
como Scrum (30), Kanban (31), XP (32) ya están causando muchos cambios e
impacto en las organizaciones de a pocos. Lamentablemente y como pasa siempre
en nuestro País, nos enteramos o adoptamos algo cuando ya en nuestros vecinos
Argentina, Chile, Colombia, Brasil, por mencionar algunos ya vienen tras cuatro
años practicando y aplicando.
Hoy por hoy también invito al
lector a revisar sobre Lean Software (33) pues esto les permitirá ver que no
siempre hay que estar pegado al estándar si es que este no nos permite marcar
la diferencia. "Piensa
en grande, actúa en pequeño, equivócate rápido; aprende con rapidez".
Estas metodologías tienen un común denominador y
que es parte del manifiesto ágil (34) que dio lugar a todo: Dar importancia al
equipo, las personas, sus interacciones; al software como nuestro objetivo
final, el cual debe funcionar y no depositar nuestra confianza en sólo
herramientas, o documentación exhaustiva, a dar valor en resumen a lo que es
estrictamente necesario; trabajar en un esquema basado en iteraciones o ciclos
cortos para obtener un mejor feedback del cliente, lo cual implica no tener un
contrato en el cual el cliente y el proveedor no tengan una relación
win-to-win. El punto es tener a las dos partes como ganadoras. Entonces tenemos
que poder responder al cambio, por lo cual los cronogramas Gantt se van a la
basura. Cronogramas que nunca han reflejado la verdad y solo dan
aproximaciones. Entiéndase bien: No se puede predecir el futuro.
Ante todo esta parte metodológica mencionada
anteriormente. Las exigencias de hoy entonces te piden desarrollar cosas “para
ayer”. Durante los últimos años muchas empresas sobre la base de estándares
java desarrollaban su Framework de Trabajo, lo que originaba tener un
Arquitecto que daba mantenimiento a ese framework y llenarlo de todo lo que se
necesitaba por proyecto creándose unos “Transformers” de arquitecturas para dar
soporte a todas las necesidades.
Por suerte estos últimos años, toda esta onda
ágil ha traído innovación e iniciativas open source para crear aplicaciones más
rápidamente sin sacrificar buenas prácticas y performance. Iniciativas como
Spring Roo (35), Grails (36), Play (37), Vaadin (38), Lift (39) han salido al
mercado. Todas ellas open source, y dando soporte a nuevos lenguajes para la
plataforma java como Groovy (40).
En particular he probado Spring Roo, que para
entenderlo bien hay que conocer muchos de los proyectos de SpringSource.com,
JPA. Grails me pareció una muy buena
idea como respuesta a Ruby (41) & Rails (42) que es otro mundo y no solo
optar por JRuby (43), sino convertirse en un framework MVC para desarrollar con
java y Groovy.
Play es como dice su traducción para desarrollar
como jugando. Es muy sencillo de usar y basado en Scala (44) un lenguaje del
cual también debes enterarte y que merece un artículo aparte. Está basado en
Scala en su parte interna, pero puedes desarrollar con java. Permite recargar
tus clases java sin bajar el contenedor.
Los otros no los he probado pero, puedes visitar los
links que adjunto para enterarte por ti mismo estimado lector. Aunque se puede criticar que solo sirve para
hacer mantenimientos simples, para alguien que los ha usado y personalizado,
les puedo asegurar que es una buena iniciativa y que no deberíamos desestimar.
Hay buenos casos de éxito en países vecinos y en el extranjero. ¿Que esperamos?
¿Queremos sorprender al jefe? ¿Queremos destacarnos frente a la competencia con
nuestra capacidad de delivery? Entonces te invito a leer más sobre ellos.
Espero les sea de utilidad y si se ha compartido
mis datos personales, gustosamente podré colaborar con ustedes. Su colaborador
José Díaz.
Elaborado para una revista en la universidad de Abancay.
0 comentarios:
Publicar un comentario