Diseñando una arquitectura (IV/IV): Conclusiones

Aquí acaba el trayecto en el que he pretendido volcar prácticamente mis últimos dos años de trabajo.


IV. Conclusiones

Generales

El uso de librerías más avanzadas con el fin de aumentar la productividad exige más del programador. Cualquiera puede picar código a destajo, pero no todo el mundo tiene la misma facilidad para abstraerse y pensar en términos de capas, de objetos... No es sólo una cuestión técnica, por ejemplo, de "saber Hibernate". El uso de estas herramientas revaloriza la capacidad para trazar errores, para hacer código correctamente encapsulado, para aprender nuevas tecnologías... La aptitud de los programadores es, por tanto, más importante que nunca.

Obviamente también lo es la actitud. Entre las quince o veinte personas que se han enfrentado con el "nuevo framework" y el nuevo entorno de desarrollo hemos encontrado actitudes muy diferentes. Por ejemplo, con un nuevo IDE, los hay que en tres días se han aprendido todos los atajos para las acciones frecuentes, y los hay que dos años después siguen usando el ratón para guardar un fichero. Los hay que incluso llegan a trazar el código de las librerías en busca del error (alguno llegó a mirar código nativo de la JVM) y otros que insisten en redesplegar cuando algo no funciona, "por si acaso". Los hay que en el foro o por correo exponen el problema enseñando trazas, código, etc, y los hay que dicen "no me funciona".

La aptitud y la actitud son algo difícilmente controlable. Las medidas más importantes que se pueden tomar son mejorar los procesos de selección de personal, formación, e incentivar. En otra ocasión me extenderé más con la experiencia ganada en estos aspectos, quiero evitar otra entrada infinita como la anterior.

Entorno de desarrollo

A lo largo de casi dos años ya nos hemos encontrado varios bugs en MyEclipse, pero nada grave. Es un buen entorno de trabajo, aunque si no hubiésemos necesitado la integración de Matisse (no sé si ya habrá plugins gratuitos que lo integren, por aquél entonces no) yo me habría ceñido a Eclipse sin más. Fundamental el valor añadido que aportan otros plugins, como elJadClipse para la ingeniería inversa, o PMD y FindBugs para la calidad del código. La integración con JSF, Spring o Hibernate me parece decepcionante. Los asistentes para añadir capacidades de dichas librerías a los proyectos me parecen innecesarios y conflictivos. No está muy claro cómo decir, por ejemplo, que un proyecto ya existente "es JSF" o "es Spring", los asistentes están muy orientados a cuando se parte desde cero.

Eso sí, el detector de conflictos en el código CVS es lamentable. Especialmente cuando trabajas con varias ramas, resolver los conflictos con él es un suplicio. A veces estoy recurriendo al Araxis Merge para solventar las carencias del Eclipse en este sentido.

Tener que usar SJSAS 8 como servidor es un infierno. El problema no es los bugs que pueda tener (todas las aplicaciones los tienen), sino el soporte que existe en la comunidad open source sobre él. Las librerías están probadas y soportadas siempre sobre Tomcat y JBoss, los demás servidores sólo marginalmente. A menudo ni existe información (ni en la documentación ni en los foros) sobre otros servidores, y cuando hay suele estar obsoleta o incompleta. Además, el soporte técnico (la principal razón para utilizarlo) se suele lavar las manos cuando te encuentras con un problema, alegando que es un tema de la librería, no del servidor. En breve nos enfrentaremos a migrar a SJSAS 9, que esencialmente es el Glassfish 2, que sí es open source,  lo cual supongo que mitigará el problema.
No dudo que SJSAS sea un buen servidor, con buenas herramientas de administración, clustering y demás. Mientras todo funcione no hay problema. Sin embargo, cuando aparece un error, la sensación de desamparo es tremenda.

Generalidades sobre las librerías

Cuando te bajes las librerías, bájate también el código fuente y configúralo en Eclipse al configurar las librerías. Esto te permitirá tener el javadoc del código y depurar. No es que vayas a modificar su código, pero cuando te encuentres con una excepción inesperada podrás trazar para localizar el problema. El trabajo de documentación y de tratamiento de excepciones en librerías Java de código abierto suele ser excelente, pero cuando no lo es, disponer de esto es impagable.

El trabajo de integración (incluyendo resolver los problemas que aparecen a posteriori) de las librerías de vista (MyFaces, Tomahawk, Sandbox, Facelets y RichFaces) en el SJSAS es problemático. Así como la convivencia de Spring e Hibernate es perfecta, el resto no lo es. Por favor, ¡integración de Facelets en JSF ya!

Algunos dicen que el framework tiene demasiadas librerías, pero yo opino que incluso le falta alguna. En vez de utilizar un motor de workflow existente (jBPM, Enhydra Shark...) hemos desarrollado uno propio. Si bien creo que lo hecho está muy bien, IMHO ha sido un error. Habría sido mejor tomar uno existente y desarrollar sobre él para mejorar sus carencias.

Hibernate

Ya me he expresado varias veces muy en favor de Hibernate, el cual recomiendo encarecidamente. Aquí me centraré sólo en los puntos negativos.

Hibernate no es intrínsecamente lento ni devorador de memoria (de hecho, correctamente usado incluso puede optimizar ambos aspectos), pero hay que "atarlo en corto". Es muy fácil no darse cuenta y provocar que la carga de una página genere cientos de consultas. Abstraer el acceso a datos es fantástico, pero si no se pone cuidado es fácil que se vaya de las manos.

El polimorfismo y la herencia desde el punto de vista de la programación es elegante y potente, pero genera consultas monstruosas. Úsese con moderación. Nuestro DBA me miró asustado al ver que una consulta ocupaba aproximadamente siete folios (espacio simple, fuente 11 aproximadamente :) ). Sin embargo, hay que admitir que el rendimiento de Oracle en estos casos es espectacular. Bastó con mejorar una vista (era de sólo lectura, así que "materializarla" fue una solución óptima) para que se ejecutase sin problemas de coste. Mi recomendación es exprimir Hibernate al máximo, haciendo el código lo más elegante y correcto posible, y optimizar a nivel de BBDD. Si aún así algo se vuelve lento, siempre se puede optimizar ese punto en concreto.

Algo similar a nuestros problemas con el (nulo) soporte a SJSAS ocurre con el combo Hibernate + Oracle, especialmente en la gestión de datos binarios. Sin embargo, afinando un poco con el driver y utilizando alguna mejora que ofrece Spring al respecto, no hay problema sin resolver.

JSF

Como ya hemos dicho, sólo es una base. Facelets es imprescindible (¡estándar ya!). RichFaces es una gran librería para Ajax.

Posted by Juan Ignacio Sánchez Lara 14:58  

3 Comments:

  1. Anónimo said...
    Una serie de posts muy interesantes. Gracias por compartirlos.
    cocorossello said...
    Interesante artículo.

    Coincido en un montón de cosas contigo. La actitud es absolutamente todo.

    Aunque lo cierto es que es complicado mantener una actitud correcta cuando te han impuesto un determinado framework, estas cosas muchas veces pasan. Por lo tanto, tiene que ser una mezcla de actitud, consenso y voluntad por parte de todos.

    Respecto a lo que comentas de myeclipse, a mí me gusta mucho más netbeans (a partir de la 6.1). Tiene fallos también, pero no son comparables en mi opinión a los de eclipse, que hereda demasiado código ya. Pero bueno, en cuanto al ide es cuestión de gustos y costumbres y en costumbres netbeans tiene muy poco que hacer (antes era muy malo).

    Lo que comentas del cvs, prueba subversion :)

    Por último, hibernate (o cualquier implementación de jpa) es imprescindible ya en cualquier proyecto. Que te haga las cosas más fáciles no te salva de que entiendas qué está pasando por debajo y de vez en cuando tengas que mirar las consultas que "está escupiendo" y por supuesto tampoco te salva de dominar sql. Pero te hace todo mucho más fácil.
    Nacho said...
    Gracias por los comentarios. Para desarrollar ya me he acostumbrado a Eclipse, pero tengo recién instalado NetBeans para UML :)

Post a Comment