Methods & Tools est fier d’être le sponsor média d’un certain nombre de conférences, mais je n’ai malheureusement ni le temps ni le budget pour assister à la grande majorité d’entre elles. Cette année, j’ai pu trouvé un peu de temps pour aller à Zürich assister le mercredi 24 juin à la conférence Jazoon, un événement majeur pour Java en Europe. A part la session plénière, la conférence offre cinq salles de présentations en parallèles. La première activité du matin consiste donc de faire son choix entre 30 présentations, ce qui un peu plus facile pour moi puisque je ne suis pas un spécialiste Java et je peux ainsi me concentrer sur les sujets qui ont un intérêt en dehors de la communauté. Voici le compte-rendu de deux sessions qui touchaient au thème de l’agilité.

La première session s’intitulait « Refactoring of Large Software Systems », présentée par Sibylle Peter et Sven Ehrke de Canoo Engineering AG. Elle traitait du refactoring d’une architecture logicielle corrompue dans une banque suisse. Les développeurs initiaux étaient partis et il n’y avait que peu de tests fonctionnels disponibles. Des évolutions importantes étaient ainsi repoussées, car toutes modifications créaient des effets de bords incontrôlables. Cependant, cette application était très importante pour la banque qui comptait l’utiliser encore pour quelques années. La première activité a été d’analyser les 1800 classes Java et leurs dépendances. La stratégie a ensuite consisté à restructurer le contenu des classes pour séparer clairement les fonctions de services et de présentation en utilisant une architecture orientée services (SOA). Le projet, qui se déroule sur un mode agile, n’est pas terminé et a déjà consommé 10 années/hommes. La programmation en binôme a été un élément essentiel pour s’assurer que le refactoring était effectué de manière consistante à travers l’équipe. Le principal ingénieur du client sert de « product owner » et joue un rôle fondamental en permettant à l’équipe de Canoo de disposer d’une personne capable de prendre des décisions en connaissant les interactions de l’application avec le reste de l’informatique de la banque. La décision de faire le refactoring sans modifier les fonctionnalités a été un autre facteur important de succès. Ceci a permis de tester les résultats du refactoring en comparant les résultats avec ceux l’application originale. C’est aussi un moyen de gagner la confiance des utilisateurs qui étaient un peu inquiets de laisser une équipe externe restructurer une application critique. Les progrès du refactoring ont rendu possible qu’une équipe de la banque recommence à faire évoluer le système. Parmi les enseignements tirés de la première phase du projet figure la nécessité d’investir au niveau de l’automatisation des tests et de l’intégration continue. Il faut également communiquer fréquemment entre l’équipe de refactoring et les développeurs de la banque afin de synchroniser la vision architecturale et pour effectuer un transfert de connaissances. Il est important de ne pas sous-estimer le temps nécessaire pour que l’équipe de refactoring connaisse les fonctionnalités de l’application afin de pouvoir tester ses modifications. Les présentateurs devraient écrire un article sur cette expérience qui paraîtra dans le numéro de décembre de Methods & Tools.

La présentation suivante s’intitulait  » The Power of Value – Domain Driven Design and Value Objects » et était faite par Dan Bergh Johnsson d’Omegapoint. Bien que j’aie initialement un peu peur que cette présentation ne contienne trop de code Java, Dan a vraiment atteint son objectif qui était de démontrer comment on pouvait refactorer du code pour le rendre plus compréhensible, même pour un expert du domaine qui n’a pas de connaissance de programmation… et il l’a fait d’une manière vivante et drôle, ce qui est appréciable lorsque l’on s’est levé à quatre heures du matin pour aller assister à une conférence et que l’effet de la caféine commence à décliner. Sa définition d’un objet de valeur est « un objet associé à des données et du comportement et qui a une valeur conceptuelle ». Sa conclusion est que les objets de valeur aident à diminuer la complexité (et les objets de valeurs composites encore plus) et qu’ils améliorent la testabilité et les évolutions. Dans la seconde partie de sa présentation, il a pris l’exemple d’une partie de code dédiée au règlement d’un achat par carte de crédit et l’a complètement refactorée en suivant les principes présentés initialement.

J’ai aussi eu la chance de rencontrer certains des organisateurs de Jazoon, Christian Frei et Andreas Knobel de Keynode. Ils ont été très sympathiques avec le francophone que je suis. Ils étaient très content d’avoir plus de 1000 participants, en augmentation par rapport à 2008, dont près de 50% provenant de l’extérieur de la Suisse. Des vidéos de la conférence devraient être disponibles sur l’excellent site Parleys.com.

Autres articles intéressants :


Comments

Name (obligatoire)

Email (obligatoire)

Site web

Speak your mind

*