J2eeEtAgilite
Un article de Agile-Swiss.
A J2EE ilité ? Quelques réflexions pleines de mauvaise foi (et d'un peu de bon sens) sur la plateforme J2EE. Certaines pratiques fréquemment rencontrées me semblent bien peu Agiles. La courbe d'apprentissage s'allongeant dangereusement, certaines alternatives (dans certains cas) sont peut être à considérer.
Sommaire |
;-)
... For me, the answer was that I have long been looking for a simpler way to build web-applications. I'm a J2EE developer, and it seemed that every project I joined had a different set of frameworks. All of those frameworks could be configured to work together, and there are even frameworks whose only purpose is to make other frameworks work together. There are tools that generate stubs to wrap frameworks, and frameworks that wrap other frameworks, so that the developer needs not know what the underlying framework is. Madness. ...
Extrait d'un commentaire sur "Agile Web Development with Rails (The Facets of Ruby Series) (Paperback)" par M. de Mare (Amsterdam)
Voilà. Le serpent se mord la queue, non ? Ce qui me gène avec la complexification de J2EE, c'est que toute l'infrastructure censée standardiser des besoins récurrents devient une gène à la compréhension synthétique d'un projet donné. (Je ne citerai aucun exemple volontairement, regardez donc votre environnement J2EE). Par compréhension synthétique j'entend :
- la vitesse d'apprentissage de l'environnement - la rapidité de débug - la facilité avec laquelle on peut maintenir le code et faire évoluer l'environnement de développement - la rapidité avec laquelle on peut mettre en place un environnement de développement.
One size fits all ?
Complexité, verbosité
Trop de configurations (ah la verbosité d'XML :-) éparpillées dans plein d'endroits. Cette verbosité est telle d'ailleurs qu'elle s'accompagne obligatoirement des plug-ins dédiés aux principaux IDE. Résultat : on gagne encore en complexité, avec l'installation de ces plugins dans l'IDE (gestion des versions de ces plug-ins, compatibilité avec les versions de l'IDE lui-même, ...) Cerise sur le gateau, vous êtes maintenant liés (à vie au moins !) avec votre IDE (pas si favori que ça parfois) sur un projet donné. Hors de questions aussi de laisser à chaque développeur (ou binome) le choix de son IDE. Serait-ce une bonne idée ?
Dans le même ordre d'idées, les insuffisances d'une architecture ultra-générique ont vu des extensions propriétaires côté application servers. (deployment descriptors propriétaires) Le framework qui se veut universel se heurte à la réalité de chaque projet, et la promesse de portabilité initiale s'envole.
Généricité
Nombre de solutions dans la sphère J2EE sont obsédées par la généricité. Ne dites pas à mon code qu'il attaque une base de données, il croit qu'il s'adresse à une entité de persistance ! Présumer que rien n'est défini, est-ce Agile ? Un extrait d'un des conseils de
Top 8 Architecture Tips for Distributed Computing by Richard Monson-Haefel 05/01/2000
... The object model is ephemeral; the data is permanent. In other words, its more likely that your relational database will last into the next decade then your OO application. ...
Combien de fois ai-je entendu :
"Et si on change de database ?". "- Est-ce probable ?" "Non, mais si on changeait de database ?" "Faisons les choses suffisamment simplement pour s'adapter rapidement, mais ne présageons pas des fonctionnalités ou changements à venir" (heu je suis parfois moins diplomate)
Ah mais alors être XP, c'est ne pas s'attendre à ces changements dont on nous dit qu'ils sont la motivation pour les méthodes agiles ? Non. La réponse au changement (inéluctable sur un projet IT) se fait avec nos amis Simple Design, Refactoring et Testing. Pas avec ce faux ami qu'est Big Design UpFront.
Top-down versus bottom-up
La racine du mal vient peut-être de ce que J2EE (ça s'améliore ?) vient de comités qui veulent normaliser au lieu de laisser les solutions s'imposer d'elles-même. i.e un besoin se fait sentir, des solutions (Open Source généralement) s'améliorent jusqu'à la maturité et le fameux standard de-facto.
J2EE comme un framework monolithique, très complexe me fait peur. En réaction, regardez la vitalité de l'offre autour de la plateforme Java. Cette vitalité a sa contre-partie (passez une semaine en vacances, et regardez theserverside : vous avez 5 frameworks de retard.;-) Cet article n'est pas une critique frontale de la plateforme Java. Mais plutôt une inquiétude quand à la direction prise par J2EE. Ironique de constater aussi le retour des POJO's : un nouveau mot pour les bonnes vieilles classes Java !
Il est possible (et souhaitable !) d'être Agile dans un environnement J2EE. Je me pose seulement la question : avons-nous systématiquement besoin de J2EE ? Ou plutôt, J2EE n'est-il pas parfois choisi parce que :
- le management pense qu'on ne peut pas faire de développements sérieux à l'échelle de l'entreprise avec autre chose - c'est "noble", contrairement à Java tout seul ou aux lanagages de scripts par exemple. - on anticipe des besoins sur-évalués en utilisant une solution sur-dimensionnée.
Un autre choix
A l'opposé, les langages de scripts.
- disclaimer Je ne veux pas faire croire ici qu'un langage de scripts peut remplacer une plate-forme comme J2EE. Simplement, ces langages peuvent être un complément efficace et mieux adaptés dans certains cas.
Au moins 3 à priori négatifs :
- danger du non-compilé (mais la pratique du Test Driven Development est sans doute une excellente protection) - Maintenance sur le long terme ? - Performance : vaste blague ! Une plateforme d'entreprise n'a pas des contraintes de performances dures. Des contraintes de stabilité, maintenance, standardisation : oui. De la puissance brute par CPU (d'ailleurs ça change tous les 18 mois), certainement pas.
L'Agilité commence peut-être par le choix d'une plateforme adaptée au projet ? Le débat est ouvert...
Liens
Beyond Java de Bruce Tate Il dit la même chose (depuis longtemps avec un autre livre Better, Faster, Lighter Java)
TheServerSide Conversations animées sur Beyond Java chez TheServerSide.
Démo Ruby on Rails A voir absolument !
Stéphane Tavera
