BreizhCamp : J2EE m’a tuer ou comment (sur)vivre avec du legacy par Emmanuel Hugonnet
Durant cette session, Emmanuel nous a fait part de son retour d’expérience sur son projet actuel et plus particulièrement comment il a réussi à transformer un code vieux de 12 ans avec les technologies de l’époque en un projet au top des dernières technologies (et donc en faire un projet super sexy 
)!
En fait, pour être plus précis, il nous a fait part de l’état de l’art du projet (qui avait débuté en 1999) lorsqu’il a pris le poste en 2008 et où il en était au jour d’aujourd’hui.
Ce petit compte-rendu va donc tenter de retranscrire comment Emmanuel a fait renaître de ses cendres un projet sur le déclin.
A noter cependant, que cette présentation n’avait pas pour objectif de parler du tout dernier framework à la mode. Il s’agissait vraiment d’un REX.
État de l’art
Pour rappel, en 1999, comme nous l’a si bien rappelé Emmanuel, il n’y avait pas de Struts, pas de Doclet, et les EJB ainsi que Britney Spears gouvernaient notre quotidien. Pour ce qui est des technologies, c’était l’époque de Java 1.2-1.3, de J2EE 1.2-1.3 (avec Weblogic/Orion) et de la toute première release de ant (qui est sortie en 2000). Coté environnement, c’était la bulle internet avec l’avènement des portails d’entreprises mais aussi avec pleins d’informaticiens (jusqu’à 40 développeurs sur le projet) et tous ça parfois dans un joyeux bazar : 300 000 lignes de code, une javadoc non maintenue, du code dupliqué (plusieurs méthodes qui font la même chose mais, bien sûr, implémentées différemment ou pas…). Tous ça avec moultes framework (en gros tous ceux qui ont existé entre 1999 et 2003)…
Au final, vous vous en doutez, si vous mettez tous ça dans une bouteille que vous rajoutez une petite pincée de CVS et que vous secouez bien, vous obtenez un truc pas très maintenable et pas très évolutif… si, bien sûr, on ne compte pas les bugs…
Enfin, si on prend en compte qu’avec l’effondrement de la bulle internet en 2004 il restait, en 2008, 3 développeurs pour maintenir un portail d’entreprise de cette envergure (en sens maintenabilité), je ne suis pas sûr qu’on aurait prédit un avenir radieux au projet.
En gros, pour résumer, on avait donc en 2008 :
- 300 000 lignes de code,
- beaucoup de bugs,
- aucun test,
- un build complexe comprenant 90 scripts ant avec une agrégation non déterministe du contenu des projets dans un jar, scripts ant différents entre les environnements (ie. des scripts pour la génération du livrable de production et des scripts pour l’environnement de développement),
- 4 heures de build,
- un SCM non adapté (gestions des branches, rollback, …).
Actions/Réactions
Remettre sur le droit chemin un projet de ce type était une tache ardue et c’est dans ce contexte qu’est arrivé Emmanuel.
Ses deux premières actions ont été les suivantes :
- Avoir un build standard avec l’utilisation de maven (ndlr : pour éviter tous troll, maven est un outil qui permet de standardiser le build mais ce n’est pas le seul… : il force aussi aux bonnes pratiques), un focus sur la reproductivité du build dans le temps et l’espace, un build en moins de 30 minutes, un environnement de développement similaire à ce qui est livré (ndlr : n’oublions pas qu’il s’agit d’un portail).
- Avoir un SCM qui répond mieux aux besoins avec un passage succinct sur SVN puis GIT et plus précisément un hébergement sur GitHub. Cela a permis une souplesse accrue pour le développement.
Ces deux actions ont permis une meilleure maîtrise de l’environnement de développement avec, entre autre, la possibilité de gérer les branches de maintenance ainsi que permettre une reproductivité du build. Du coup, cela a également permis un cycle de release mieux adapté aux besoins, c’est à dire une trentaine de release en 1 an.
Les autres actions d’Emmanuel ont été les suivantes :
- Ajout de l’intégration continue avec Hudson puis Jenkins.
- Reprise des commentaires qui étaient obsolètes.
- Gérer la duplication de code et refactorer le code “legacy” ainsi que le code mort en s’appuyant sur un framework d’IOC (tel que Spring) afin de pouvoir injecter facilement les nouvelles classes remplaçant les anciennes.
- Ajouter des TUs en utilisant des mocks/stubs.
- Passer en mode agile.
- Soigner le code en ajoutant des outils de qualité de code tels que Sonar et Kalistick afin de ne pas ajouter de “mauvais” code mais également afin de voir la progression (passage en 1 an de 76% à 56% de violations).
- Revoir la couche architecturale en :
- délaissant les frameworks “lourd” tels que le MVC1 ou les EJB 2 et ainsi pouvoir utiliser un conteneur plus “léger” tel que Tomcat au lieu de la stack complète JEE,
- privilégiant les nouvelles tendances tels que JPA2, REST ou JQuery, GWT pour la couche frontale,
- ouvrant le portail vers d’autres systèmes en terme d’interopérabilité.
Conclusion
En conclusion de ce super retour d’expérience, Emmanuel a conclu par le fait qu’un projet peut être amélioré même s’il part de loin (même si cela ne s’avère pas une tache aisée)… rendant ainsi le sourire aux développeurs, ce qui permet d’améliorer la productivité mais aussi en diminuant les risques de régression lors de l’ajout de nouvelles fonctionnalités.
En un mot : tout le monde est content !
4 réponses à BreizhCamp : J2EE m’a tuer ou comment (sur)vivre avec du legacy par Emmanuel Hugonnet
Laisser un commentaire
Licence
Sauf mention contraire, le contenu de ce blog est mis à disposition selon les termes de la licence Creative Commons.
Très intéressant de voir que certain projets arrivent à renaitre de leurs cendres comme ça.
Est-ce qu’il a donné des métriques pour la réalisation du chantier en temps, jours hommes, budgets globaux, etc?
Car souvent ce n’est pas la faisabilité qui pose problème mais plutôt les budgets pharaoniques que ça demande.
Cool que tu trouves l’article intéressant mais la prez était encore mieux !
Sinon, concernant les métriques, il me semble qu’ils étaient 3 développeurs et que le travail s’est déroulé de 2008 à ce jour (en plus des évols).
Concernant l’accord de la direction, Emmanuel n’a pas eu de soucis à priori (je lui laisse affirmer ou infirmer) puisqu’elle était demandeuse.
Enfin question budget pur, je ne sais pas.
Bonjour,
Le chantier est en cours. Je présentais le résultat de 2 ans de travail de l’équipe de Silverpeas. Durant ces 2 ans nous avons assuré la maintenance de la version précédente (avant le refactoring), la maintenance de la version courante, le développement de nouveaux features et donc le refactoring.
La première pierre a été la refonte du processus de build : une semaine à 2 pour passer le premier composant puis environ 1 mois seul pour passer les 30 autres composants sachant qu’il fallait parfois casser des cycles de compilation.
Depuis nous travaillons au jour le jour à améliorer le code tout en développant car Silverpeas étant une petite structure nous ne pouvons nous permettre d’engager un budget pharaonique dans le refactoring.
Toutes les métriques de qualité sont disponibles en ligne (le projet étant libre) sur integration.silverpeas.org/sonar et https://cockpit.kalistick.fr (silverpeas/silverpeas).
Nous n’affectons pas un budget au refactoring, on profite des développements (correction de bug, nouveaux features) pour reprendre le code. Si le refactoring est trop profond nous reculons parfois en attendant d’avoir plus de temps (là encore Git nous aide beaucoup).
Les slides : http://www.slideshare.net/ehsavoie/j2ee-ma-tuer