Il y a 12 ans -
Temps de lecture 10 minutes
Revue de Presse Xebia
La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.
Actualité éditeurs / SSII
Agilité
Le coin de la technique
Actualité éditeurs / SSII
Spring Suite Tool (STS) 2.8.0
SpringSource vient de sortir la dernière version de son IDE basé sur Eclipse : Spring Source Tool Suite (STS) 2.8.0. Il inclut désormais Eclipse Indigo SR1, avec le support de Java 7. Il ajoute également le support de Spring 3.1 pour la configuration des beans : profiles et c-namespace. De plus, l’intégration avec Maven s’améliore avec le passage de m2eclipse 0.12 à m2e 1.0 (attention tout de même, ce dernier introduit la notion de connectors qui sont requis pour lier les plugins à Eclipse mais n’existent pas pour tous les plugins Maven, certains l’ont subi avec difficulté).
Vous utilisez Spring mais pas STS? Vous devriez essayer! Tous les plugins pour Spring sont présents et le téléchargement inclut les dernières versions de Maven (3.0.3), Spring Roo (1.1.5) et tcServer (2.6.1).
L’avenir des clients Java passera par JavaFX
Durant la dernière conférence JavaOne 2011, Oracle a dévoilé sa stratégie concernant les applications clientes Java. Sans surprise, Oracle mise sur JavaFX.
Pour rappel, JavaFX est une API pour développer des RIA (desktop ou mobile), apparue il y a quelques années, mais qui n’a pas rencontré le succès escompté. Face à cet échec, une nouvelle version 2.0 de JavaFX a été présentée à la conférence JavaOne 2010.
Parmi les nouveautés marquantes, on peut noter l’abandon du langage Fx Script pour une API full Java. Cela permet notamment l’utilisation d’autres langages compatibles avec la JVM, tels que Groovy ou Scala. On voit aussi apparaître un descripteur d’interface graphique au format FXML. Celui-ci sera accompagné d’un outil graphique (standalone pour le moment), Java Fx Scene Builder, facilitant la création des interfaces. Cet outil fera son apparition courant 2012. Enfin, JavaFX pourra embarquer des composants HTML5 et JavaScript via l’utilisation de WebKit. Le projet Avatar pousse même encore plus loin, en proposant des applications hybrides avec des interactions entre le monde JavaFx et HTML5.
Afin d’accélérer son développement, JavaFX va devenir open-source et sera intégré directement dans le projet OpenJDK. En parallèle, J2ME, l’API mobile historique de Java, va être unifié aussi dans le prochain JDK.
L’objectif d’Oracle est de diffuser JavaFx sur un maximum de périphériques possibles: desktops, mobiles et tablettes. Potentiellement, tous les périphériques compatibles avec la JVM pourront supporter JavaFX. Une version bêta est d’ores et déjà disponible pour Mac OS X. Une version pour Linux (Ubuntu) fera son apparition en 2012. Au final, JavaFx 3 sera intégré dans le JDK 8 prévu pour 2013 et sera compatible avec toutes les plateformes.
Agilité
Estimations
Un sujet revient régulièrement lorsque l’on parle d’agilité, c’est celui de la planification et de l’estimation de la durée d’un projet. InfoQ a d’ailleurs publié récemment 3 articles dédiés au sujet.
Le 1er article parle de la problématique d’estimer un projet dans sa globalité. Un tel problème fait toujours bondir les agilistes ! En fait, plus le contexte est connu et maîtrisé par l’équipe de développement, moins il est malhonnête de faire des estimations. Mais celles-ci sont généralement difficiles. Une idée évoquée est de démarrer avec un scope fixe permettant d’éduquer graduellement le client à l’Agile afin de lui ouvrir les yeux sur le mirage du périmètre fixe. Dans les commentaires, on trouve des avis contradictoires, mais tous valables. Adam Nemeth par exemple, s’exclame que les estimations sont inévitables: nous sommes payés pour résoudre les problèmes qu’ont d’autres et ils attendent les solutions pour une date donnée. Il est par exemple inconcevable de sortir le site internet des JO d’été de 2012 en hiver par la faute d’une erreur dans le chiffrage des tâches. Mais, plus loin dans son commentaire, on se rend compte que lui est capable de bien planifier car il a la chance de travailler dans un environnement stable avec des patterns de problèmes identiques pour lesquels il a pu mettre en place une solution qui s’applique à chaque fois. Dans un tel environnement « idéal », il n’est pas inconcevable de pouvoir chiffrer aisément avec une bonne approximation.
Le second article se demande si le temps est venu d’arrêter d’estimer les user stories. On retrouve là aussi, en caricaturant, une distinction entre ceux qui pensent qu’il vaut mieux créer un produit de qualité et ceux qui pensent que les estimations sont, bien que science inexacte, un mal nécessaire. Les commentaires, une fois de plus, ne sont pas inintéressants. Josh Gough y décrit ce dans quoi certains se reconnaîtront: il parle des « guesstimates » (estimation basées sur rien de concret) et des « wishtimates » (lorsque la date prévisionnelle de fin de projet prise en compte est la date idéale) qui sont souvent utilisées en lieu et place d’estimations vraiment réalistes. Pour lui, elles sont généralement basées sur des aspects politiques ou des facteurs psychologiques qui donneront à la personne inexpérimentée qui est en charge une fausse sensation de contrôle. Que faire lorsque le management attend de vous non pas un intervalle de risque mais une date fixée dans le marbre ? Il préconise de manière pragmatique d’essayer de s’appuyer sur des données empiriques et factuelles ainsi que de sensibiliser les personnes à la complexité des projets, des tests et du risque. Plus loin, ce même Josh Goush utilise une analogie avec le travail d’un peintre. Confieriez-vous la peinture de votre maison à un peintre vous ayant fixé un prix sans même vous avoir demandé le nombre de pièces et leur taille ? En développement logiciel, c’est le même principe exception faite que la taille et le nombre des pièces est extrêmement dur à appréhender. Et nous revenons ici au principe de base de l’agilité qui est d’adapter le projet au fur et à mesure de son avancement aux besoins changeants du client. D’où l’impossibilité de déterminer une fois pour toutes un chiffrage en amont du développement.
Enfin, un troisième article se demande ce que signifie le « rythme soutenable » évoqué dans le manifeste agile et comment y parvenir. Le lien avec la difficulté d’estimer un projet est vite réalisé: il est fréquent que des estimations initiales prétendent tenir compte de tous les évènements imprévus (!). Dans ce cas, il n’y a plus que les heures sup’ pour absorber les vrais évènements imprévus qui ne manquent pas de survenir. Au final il semble que tout le monde s’accorde à dire que les premières victimes d’un rythme élevé sont toujours la qualité et les bonnes pratiques.
Les métriques du bonheur
Qui a dit que les métriques, si chères à notre gestion de projet, sont tristes et vous donnent le cafard le lundi matin en stand-up? Que dire des courses à l’indicateur, pour atteindre l’objectif chiffré, quoi qu’il en coûte!
Anders Laestadius, coach agile suédois de son état, nous propose une liste de quelques métriques que son expérience lui indique comme nécessaires:
- la mesure de bonheur ou de stress de l’équipe, pour la partie management
- le pourcentage de duplication de code, ainsi que la couverture de tests, pour la partie conception de l’application
- Le release burn down et lead time pour suivre l’engagement du projet envers le client.
Avancement du projet
L’un des incontournables de la méthode SCRUM est la mesure du Release Burn Down. Anders préconise le suivi de la Release plutôt que du sprint, ce qui est plus en accord avec la vision client.
Lors de l’utilisation de la méthode Kanban, il préfère utiliser le « Lead Time ». Il consiste à mesurer le temps que met une tâche pour sortir du système. Il permet de connaître le taux de « réactivité » de l’équipe et sa capacité à absorber une certaine charge de travail dans un intervalle de temps donné.
Santé technique de l’application
Selon l’auteur,le taux de duplication de code est le meilleur indicateur de qualité de code pour une application. Un code trop souvent dupliqué soulève un problème de conception avec du refactoring à prévoir. De plus, cela est source de bugs et d’effets de bord. Facile à détecter, et relativement facile à corriger.
Pour le taux de couverture de code, le Test Driven Development reste la solution numéro 1 pour l’améliorer efficacement. Les outils de couverture de code, comme Cobertura, permettent de rapidement voir les portions de code non testées, pour améliorer encore et toujours la robustesse de nos applications.
L’équipe
L’indicateur de « bonne humeur » d’une équipe permet de voir d’un autre point de vue l’équipe. On ne parle plus d’effort, de vélocité ou de taux de progression. La bonne humeur est directement liée à la motivation de l’équipe à respecter l’engagement du sprint. On peut aussi utiliser l’indicateur de « Stress ». Cela permet aussi de détecter, lors des creux, des problèmes qui déstabilisent l’équipe, pour mieux les résoudre ensuite. Mais attention, stress et motivation ne sont pas forcément contradictoires. Le daily scrum meeting ou la séance de rétrospective de SCRUM sont les moments privilégiés pour mesurer cet indicateur.
Le coin de la technique
Continuous Deployment
Pour ceux qui n’ont pas encore entendu parler du déploiement continu, Ranjan D. Sakalley nous propose une excellente introduction sur le sujet.
Ce processus n’est que la suite logique de l’intégration continue. Il consiste à déployer son application le plus rapidement, le plus sûrement et donc, le plus souvent possible. On est toujours dans l’esprit d’avoir un cycle de travail court avec un retour rapide sur ce qui a été développé, pour corriger au plus tôt et ainsi réduire le coût global de mise en oeuvre de l’application. De célèbres exemples, comme Flickr et Github sont capables de mettre en production leurs applications plusieurs fois par jour, oui par jour!
Pour arriver à un tel niveau de maturité, il faut se doter d’une couverture de tests exemplaire et surtout, cela impose la nécessité d’automatiser tous ces tests.
L’exemple donné révèle rapidement le besoin d’avoir une équipe de 50 testeurs pour arriver à recetter une application de taille moyenne en 2 heures. On précise aussi que l’investissement initial a été de deux développeurs pendant deux mois pour la création des scripts de tests.
Si on doit livrer son application plusieurs fois par jour, on voit tout de suite la nécessité de l’automate.
L’article souligne aussi que l’automatisation des tests simples et répétitifs libère du temps aux testeurs qui peuvent ainsi aller plus en profondeur sur le code existant, pour ainsi trouver des bugs plus profonds. Cela rend au passage leur journée de travail plus intéressante, ce qui n’est pas rien en ces jours d’hiver qui s’obscurcissent!
L’auteur nous rappelle aussi qu’il est autant nécessaire de tester les aspects fonctionnels que non-fonctionnels, comme la tenue de la charge ou la performance.
Ce sujet est un bon complément aux deux derniers ateliers organisés chez Xebia sur le déploiement continu, où l’on a vu comment le plugin Apache Tomcat Maven, Rundeck et DeployIt, avec Jenkins, nous aident à faire du déploiement en zéro clic après un git-push sur un repository de code. Nous publierons très prochainement un billet sur le sujet, ainsi que sur toute l’infrastructure mise en place sur Amazon EC2, avec notre stratégie d’Infrastructure as a code. Restez à l’écoute si ces sujets vous intéressent!
Commentaire