Devoxx France : "Spring est mort : longue vie à Spring"

Une présentation relative aux méthodologies agiles était également au programme de la 2e journée de l'événement. Ainsi qu'un retour d'expérience sur Google Web Toolkit

à flux tendu Devoxx est LA conférence pour les développeurs. Le développeur est donc, pour beaucoup de présentations, un sujet central.

Pour poser le cadre, après avoir vu "Mister Love" en personne (Antonio Goncalvez pour ne pas le citer), la question "Fier d'être développeur ?" est posée dès la keynote d'ouverture. L'occasion pour le speaker, Pierre Pezziardi, de lever deux questions :

1. Bien que java soit solidement intégré dans les entreprises, le rendement des projets java en général est en baisse, notamment parce que beaucoup de code écrit soit n'est pas utile, soit sert à maintenir des applications qui vieillisent mal ;
2. Pour améliorer ce rendement, le développeur doit "s'ouvrir à la complexité de ses clients, et non pas se cantonner à sa propre complexité".

Beaucoup d'autres présentations aujourd'hui reprennent l'idée que le développement logiciel doit changer, et la réponse passe en partie par l'agilité.

La première conférence à laquelle j'assiste a pour titre "Spring est mort : longue vie à Spring", titre pour le moins accrocheur !
Gildas Cuisinier, qui se caractérise lui-même comme un "Evangéliste spring", tente malgré tout de montrer de manière objective que non, Spring n'est pas mort, et loin de là ! Il n'hésite pas à utiliser de nombreuses allusions à la guerre des étoiles pour présenter les deux forces en question (je vous laisse imaginer de quel côté il situe les Siths) : Chewbacca nous a même fait l'honneur de sa présence !
Il rappelle que, si Spring (core) souffre d'une configuration basée sur le XML, cela tend à disparaitre dans les dernières versions, avec la possibilité de faire une configuration full java, sans une seule ligne de XML, depuis la version 3 (annotations @Configuration, @Bean, @Autowired, @ComponentScan, @EnableScheduling, @Scheduled, @EnableWebMvc pour ne citer qu'elles). Il souffre également de son aspect propriétaire (développé et maintenu par SpringSource), même si le caractère OpenSource et l'existence d'une communauté en font tout de même un framework très ouvert. D'autres disent également que Spring est invasif, mais c'est l'utilisation des annotations pour remplacer la configuration XML qui conduit à ce constat.
Java EE est devenu quant à lui plus séduisant depuis la version 6 et CDI notamment, en introduisant plus de simplicité, de testabilité et de légèreté. Mais Java EE souffre toujours d'un coup de migration plus élevé, ce qui constitue le principal frein à son adoption, alors que Spring semble offrir une migration beaucoup plus simple.
Évidemment donc, Spring n'est pas mort. Car, au-delà de Spring core, il y a tout un écosystème autours de Spring, qui évolue lui aussi : Spring MVC, Spring WebFlow, Spring Data, ou encore le tout récent Spring Roo en sont des exemples concrets.


Une présentation relative aux méthodologies agiles était également au programme : "Kanban pour les nuls". J'ai l'ai trouvée très intéressante car je ne connaissais pas vraiment ses concepts. Notamment parce que c'est une méthodologie toute jeune, qui n'est pas encore mature, aux dires des animateurs de la conf'.
L'idée, alors que Scrum tend à proposer un moule pour un projet logiciel, est de fournir un cadre (où règles) aux entreprises désireuses de modifier leurs processus pour tendre vers plus d'agilité, qui tient en trois points :

1. Commencez là où vous en êtes (état des lieux de la situation initiale) ;
2. Engagez vous à changer de manière incrémentale ;
3. Respectez le processus actuel, les roles et les responsabilités, tout au long de la démarche.
   

A ces trois règles s'ajoutent 5 pratiques qui sont :

1. Visualiser. Utilisation d'un tableau et de cartes Kanban pour rendre visible l'état du projet;
2. Limiter le WIP (Work in progress) : limiter le nombre d'éléments ;
3. Des règles explicites adoptées par l'équipe, et qui évoluent au cours du temps ;
4. Mesurer et piloter. Cela passe par la sélection d'indicateurs pour guider et piloter les décisions, de manière à gérer/anticiper les blocages remontés lors des daily meeting ;
5. Amélioration. Les blocages doivent déclencher le dialogue et mener à des actions collaboratives.
   

A la différence de Scrum, il n'y a pas d'estimation a priori des User Story : c'est la cadence et le rythme développés lors des itérations précédentes qui permettent, par des calculs mathématiques, de déduire une prédiction fiable des délais pour produire.
Autre élément important de cette méthode : le concept de "flux tiré". L'idée est que lorsque vous avez une tâche qui est considérée comme terminée, on tire toutes les autres vers le done avant d'en faire rentrer une nouvelle. Les speakers font le parallèle avec la production à flux tendu de l'industrie automobile : le développeur ne se dit pas "je dois produire toutes les spécifications" mais au contraire "j'ai besoin d'une nouvelle spécification".
Bref, comme toutes les méthodologies agiles, chaque entreprise doit choisir celle qui lui convient le mieux, et Kanban peut être la réponse appropriée.

Les méthodologies agiles sont là aussi pour garantir la qualité de nos applications.  C'était justement le sujet de la conférence intitulée "Pour un développement durable".
Je pense que l'intervenant a prêché de nombreux convaincus en rappelant avec force que la qualité n'est pas une perte de productivité, et qu'il ne faut en aucun cas opposer les deux. Non, "écrire du logiciel n'est pas jouer à une partie de Jenga!". Les DSI doivent investir sur l'équipe de développement car c'est un vrai métier, et garantir un équilibre et un mentoring entre les jeunes développeurs et les développeurs plus expérimentés. Là où le manifeste agile prône un logiciel livré qui fonctionne, le manifeste "Craftmanship" ajoute à cela un objectif de qualité au logiciel livré. Après être revenu sur ce qu'il a appelé "le mirage de l'offshoring", le speaker conclut finalement que, si la qualité a un coût, la réduire coute toujours plus cher à long terme.


J'ai aussi participé à un retour d'expérience sur GWT : "Google Web Toolkit à l'épreuve du feu", au travers d'une application en charge de connecter des utilisateurs en audio et/ou web conférence. Constituée d'un back-office et d'un front-office, les fonctionnalités à présenter sont très riches et doivent répondre avec des temps de réponse très courts à de très nombreux événements : le fait qu'un des clients connecté en audio conférence raccroche son téléphone fait apparaitre quasiment instantanément un certain logo dans l'IHM. GWT a été choisi pour répondre à ces contraintes, et la présentation était l'occasion d'indiquer quelques défis techniques relevés par l'entreprise en charge du développement. On peut notamment citer :

• la fragmentation des fichiers de javascript (permise depuis GXT 2) ;
• l'utilisation du framework OpenSource GWT event Service en mode short-pulling, qui permet aujourd'hui de gérer 25 appels par seconde ;
• l'utilisation d'un autre framework open source, Jacob, pour interfacer le server avec l'application .NET qui fait le pont entre les clients et l'application Java;
• Selenium, pour les tests d'IHM.
  

Cette présentation montre bien que GWT est un framework totalement compétent pour des applications performantes avec des interactions utilisateur riches.


Enfin, cette journée m'a permis de découvrir de nouveaux outils ou langages. Je pense notamment à FluentLenium, une API basée sur Selenium mais beaucoup moins complexe à utiliser, avec notamment un syntaxe à la jQuery (mais en java, si si!). Je pense également à Ceylon, présenté notamment par le très bon Emmanuel Bernard, qui a enchaîné les boutades. A ce sujet, toutes les conférences seront disponibles sur parleyz. Je vous conseille donc vivement de les regarder, et ne loupez pas, donc, celle sur Ceylon !

La conclusion de cette journée pourrait être que nous, développeurs, pouvons être fiers de notre métier. Il faut cependant changer faire évoluer nos méthodes de développement, pour prendre en compte au mieux les besoins du client, en ne rognant pas sur la qualité.
Cela va de paire avec la poussée des méthodes agiles, qui permettent notamment une flexibilité dans la prise en compte des changements de besoins sur nos projets ainsi que la confiance en nos engagements.
L'agilité met également l'équipe au cœur du développement logiciel. Mais il faut aussi que les mentalités changent : être développeur à 35 ans n'est pas une tare, mais une chance pour l'entreprise qui peut s'appuyer sur une expertise apprise et démontrée.
La suite, demain... et j'espère que les masseuses seront encore là !