• facebook
  • flickr
  • google
  • instagram
  • lastfm
  • linkedin
  • spotify
  • twitter
  • Goodreads
  • GitHub
  • juanignaciosl.github.io
  • Medium

Postmortem “Diseñando una arquitectura”

En este blog acumulo casi 10 años de entradas, la mayor parte de ellas totalmente irrelevantes y prescindibles, y otras sencillamente erróneas. Sin embargo, quería rescatar del cajón de los recuerdos una serie titulada “Diseñando una arquitectura” que hice en 2008, para analizar cómo ha cambiado el desarrollo del software y yo mismo en este tiempo.

Disclaimer: en 2008 utilicé, de forma incorrecta, el término arquitectura, mezclando el diseño lógico con la pila tecnológica. Concededme esa misma licencia hoy, por favor.

En ella retrato mis años previos, las decisiones recientes, y las venideras al respecto del stack tecnológico en un equipo de desarrollo. Para quien no se lo quiera leer, resumiré los antecedentes en “venimos trabajando con JEE, con un buen puñado de cosas a mejorar, y queremos evolucionar, ¿qué podemos hacer?“. La evolución se tradujo, tras ver las alternativas, en pasar a una plataforma que incorporaba librerías que suplían carencias del puramente estándar JEE. A la hora de implantarlo lo más destacable fue descubrir la potencia (y complejidad) de Hibernate, las gravísimas carencias de JSF por aquel entonces, y la interesantísima RichFaces. Acabé razonablemente satisfecho con el resultado, aunque asumiendo introducíamos complejidad añadida, lo que resultaba más exigente para el equipo. El trabajo futuro se tradujo en una nueva evolución hacia nuevas versiones de varias librerías y, sobre todo, la adopción de Seam.

Trabajé a través de esas evoluciones aproximadamente 6 años, en diferentes posiciones de decisión, pero siempre en las trincheras, desarrollando, adquiriendo un dominio razonablemente bueno de las tecnologías implicadas: Java, Hibernate, Spring, Seam… Sin embargo, el otro día, tras algo más de año y algo separado de ellas, algo me invitó a hacer esta retrospectiva. En la actualidad, por un lado, estoy realizando labores de mantenimiento (correctivo y evolutivo) de un proyecto aún más viejo que las tecnologías anteriormente implicadas (JSP, esencialmente). Por otro, estoy abordando proyectos personales con tecnologías y conceptos más actuales (móvil, REST, AngularJS, Scala…). Eso se traduce en que estoy un poco oxidado a la hora de solucionar problemas con las conversaciones de Seam, la sesión del usuario, la sesión de Hibernate… Un compañero me planteó una cuestión que, meses atrás, apuesto a que habría respondido en modo automático. Sin embargo, en ese momento, sudé para dar con el tornillo que ajustar, y tuve que ofrecer dos o tres alternativas sin estar seguro de cuál era la correcta. Tras saber que la solución se encontraba entre las propuestas momento en el que siempre respiras aliviado-, en mi cabeza resonaban preguntas: ¿Tanta complejidad era necesaria? ¿Qué me aportaba? ¿Qué escogería hoy?

Enterprise Architecture

Complejidad

Cuando llevas cinco años metido en medio del berenJEEnal de servidores de aplicaciones, diseño por capas, componentes, frameworks, etc, es difícil evaluar cuán complejo es algo. El abuso de la sesión de usuario condujo a la necesidad de las conversaciones. La adopción de ORMs stateful implicó complejos mecanismos de gestión del ciclo de vida de las entidades. El barroco diseño de JSF (interno especialmente) condujo a necesitar librerías que lo simplificasen y completasen… Y, por supuesto, la combinación de estas complejidades fue, a su vez, un problema en si mismo. A día de hoy creo que JEE es innecesariamente complejo debido a una sucesión de patadas hacia adelante.

¿Qué aportaba?

¿Algo bueno tendría tanta complejidad, no? Sí, sin duda. Huyo de los generadores de CRUDs porque siempre hay tanto que personalizar que acaban siendo contraproducentes, y la combinación de JSF, Seam e Hibernate permite ser muy productivo a la hora de hacer aplicaciones de gestión con decenas de formularios y tablas. RichFaces es una buena librería de componentes (de las mejores aún hoy para este tipo de aplicaciones) y permite incorporar Ajax con facilidad. La calidad de todas estas librerías y de su documentación es excelente, siendo además open source, y con una actividad constante, que nos permitió ir evolucionando sin cambios dolorosos: íbamos incorporando nuevas librerías, actualizando las existentes, utilizando diferentes servidores de aplicaciones… Esto no es nada despreciable cuando tienes que tener en cuenta a una plantilla amplia, que rota, un equipo de sistemas que tiene que dar servicio a mucha gente…

¿Qué escogería hoy?

Para aplicaciones semejantes, en entornos semejantes, con restricciones semejantes, creo que la decisión de seguir evolucionando dentro de una pila “medio estándar” JEE  no es mala. Esta decisión, conservadora, siempre y cuando se estableciese una política de mejora continua (¡nada de frameworks corporativos!) permite bastante margen de maniobra. Parece que PrimeFaces ha cogido el testigo de ser la mejor libería JSF (seguido de cerca por RichFaces). Seam se diluyó en los siguientes estándares. Hibernate siguió mejorando y estandarizándose. Java va a dar un salto cualitativo enorme en Java 8. Si no quieres JEE, puedes salirte de forma poco traumática hacia soluciones diferentes como Play o Spring MVC. El testing está mucho más depurado de lo que estaba, y hay numerosas alternativas para ayudarte con cada problema.

Sin embargo, si el contexto lo permitiese, iría a una solución cliente-servidor REST. Los navegadores ya no son lo que eran (teníamos, por ejemplo, que soportar IE6), y el uso de Javascript ha madurado notablemente. Tengo mis dudas sobre si esto sería netamente más productivo que JEE “estándar” en aplicaciones de gestión intensivas en formularios, pero creo que, objetivamente, las ventajas a día de hoy superan los inconvenientes. Si antaño me decanté por RichFaces precisamente porque evitaba trabajar con Javascript, ahora éste sería el pilar fundamental sobre el que edificar. Mayor escalabilidad, interfaces más rápidos, mejor separación de responsabilidades…

…PERO

Como resume Matt Raible en una comparativa que se ha convertido en un clásico anual, no hay una mejor decisión. Hoy más que nunca, las alternativas son muchísimas. Lo que sí tengo clarísimo es que debo evitar que la tecnología se inyecte en mi cerebro para no dejarme pensar con claridad. Un amigo hace tiempo me dijo, de forma muy diplomática, que estaba en una fase diferente de la vida al respecto de mi ceguera con ciertas decisiones de diseño. E, independientemente de la discusión en concreto, me reveló que el terror tecnológico construido me había ofuscado. En el fondo, el disclaimer acerca de la perversión del término arquitectura es revelador. En Implementing DDD, una de las dos biblias sobre Domain Driven Design, tenemos buenos ejemplos de implementación de arquitecturas diferentes al habitual diseño por capas JEE a pesar de usar tecnologías como Hibernate. Y no es que “seguir el diseño propuesto por el fabricante” sea malo en si mismo (buscar el sweet spot de cada herramienta es fundamental), lo que ocurre es que si es tu único guión, no creces como profesional.

Conclusión

Disclaimer: conclusión probablemente aburrida para ti.

Un framework corporativo, una forma de trabajar, es algo indeseable. Crea un entorno que permita al equipo, y con ello a tus productos, crecer y evolucionar. A día de hoy creo que el quid del éxito reside en ver más allá de la tecnología, aprovechar lo mejor de cada casa para cada solución y no tener miedo en cambiar, a veces de forma radical. Para muchos esto será una obviedad, e incluso a algunos les sorprenderá saber que para otros será una locura no aferrarse a la forma estándar de trabajar. ¿Conclusión aburrida? Puede…

Spoiler hipster…

Creo que sólo hay dos formas de no estar influido por las herramientas: no teniendo ni idea (lo cual no es opción, ¿NO?), o conociendo la mayor variedad posible. En los últimos años he leído todo lo que me ha dado tiempo (artículos y libros), acudido a eventos y reuniones locales, hecho cursos, pero, sobre todo, hay que HACER, por pequeño que sea (y acabado >>>> cerrado, ya sabes). Y hacer de forma diferente, para ver las ventajas e inconvenientes. Tengo varios pequeños proyectos en el tintero, pero he participado en la puesta en producción de otros, retomado mantenimiento legacy, arrancado algún juguete propio, comenzado un proyecto para mi próxima andadura freelance a punto de empezar…

Una cosa es no fijar un “framework corporativo” y otra no tener una base sobre la que empezar a construir. Estoy empezando un nuevo proyecto en el que tengo una agradable libertad. Tras haber tanteado parte de esta pila con Mis Ofertas de Viaje, estoy trabajando más “en serio” con Zurb Foundation, AngularJS, Play, Slick, Scala y PostgreSQL, probando sobre OpenShift, y experimentando con conceptos y técnicas de DDD. ¿Es esta la pila que debo usar? NO. Otro día hablaremos de sus ventajas e inconvenientes. Pero, ante todo, sólo es eso: tecnología.

2 Comentarios

  1. Cómo se carga una página en mi uso de AngularJS, Play, Slick… (I – cliente) | juanignaciosl · abril 17, 2014

    […]  3.- En nuestro caso, la carga de la página inicial, le devolverá el fichero estático index.html. Play tiene un interesante sistema de plantillas también fuertemente tipado con el que experimenté para la página de ofertas de viaje personalizadas. Sin embargo, al usar AngularJS combinar ambas tecnologías no parece natural. ¿Para qué hacer que el servidor renderice la página, cuando estamos delegando ese trabajo en el cliente? En esta aplicación opté por una arquitectura cliente-servidor “más pura”, y el servidor actúa sólo como proveedor de recursos estáticos y API REST para la consulta de datos. En este sentido, me siento muy identificado con el interesante artículo Why we abandoned server generated web pages, ideas que ya comenté en el Postmortem de “Diseñando una arquitectura”. […]

  2. Cómo se carga una página en mi uso de AngularJS, Play, Slick… (II – servidor) | juanignaciosl · abril 25, 2014

    […] equivaler a establecer sesiones de usuario en el servidor (algo que cité como un problema de base en el diseño de JEE para aplicaciones web). Cuando tienes una aplicación cliente-servidor pura, single-paged, con Javascript y REST, lo […]

¿Me dejas una respuesta?