Lyon Craft fait fort pour une première !

PC chargé, je me dirige vers l’embarcadère juste à côté de la gare de Perrache. Accueilli avec des viennoiseries et du café, c’est parti pour une journée à Lyon Craft. Je m‘appelle Loïc et le craftsmanship me passionne. Les conférences sont l’occasion idéale pour remettre en question ses méthodes, en découvrir de nouvelles et se perfectionner ! C’est un moment idéal pour retrouver d’anciens collègues ou faire de nouvelles rencontres autour de sujets communs.

Lors de cette conférence, 3 talks m’ont particulièrement intéressé.

From Legacy to Hexagonal: A Live Coding Journey

Ce talk donné par Caroline DESPLANQUES et Pauline JAMIN avait 3 objectifs bien distincts : faire du mob-programming efficace, exposer quelques bonnes pratiques de développement et refactorer du code legacy.

Le mob programming est une pratique qui consiste à coder à plusieurs personnes. L’idée est de faire monter tout le monde en compétence, autant technique que fonctionnelle. Elle permet également de réfléchir à une solution en mettant en commun ses connaissances. En revanche, il faut savoir s’organiser autour de cet exercice peu évident : à chaque itération de quelques minutes, une personne écrit le code alors que les autres lui dictent ce qu’il doit écrire. A la fin de chaque itération, une pause est marquée et les rôles changent. Les présentatrices nous proposent d’utiliser mob pour time-boxer chaque itération selon la technique Pomodoro. Avant de lancer chaque itération, un objectif clair est défini. A la fin, même si le code n’est pas terminé, on lève le crayon !

Les bonnes pratiques de développement passent tout d’abord par un ensemble d’outils mis en place pour nous faciliter la vie. Utiliser Rider ou Ncrunch pour faire du live testing, vérifier le coverage via son IDE ou utiliser des tests de mutation grâce à pitest, tous ces outils permettent de s’assurer de ne rien oublier lors de nos développements. Pour avoir des retours plus rapides et clairs tout en gardant de la pertinence, il suffit de tester par branche, c’est à dire de tester seulement le code ajouté pour l’évolution en cours.

La première étape de refactoring consistait à donner davantage de sens au code. Le typage fort permet de gagner en sémantique et d’éviter les erreurs liées au code smell “primitiv obsession”. En encapsulant les champs primitifs dans des objets, le compilateur nous empêche de mélanger les concepts. Extraire les comportements dans des méthodes nommées clairement donne davantage de sens au code. Ces comportements sont ensuite attribués aux objets responsables, empêchant d’avoir des objets anémiques.

J’ai particulièrement aimé que les pauses en fin d’itération servent au public pour poser des questions. Cela permettait d’interagir fréquemment et de “raccrocher les wagons”.

Un démarrage TDD accéléré

Test Driven Development, le classique de tout développeur ? Etant donné le peu de mains qui se lèvent à cette question, ce n’est pas nécessairement le cas. Cédric MAGNE nous rappel les trois étapes du TDD en live-coding :

• Écrire un test qui ajoute ou modifie un comportement. Ce code ne devrait pas être valide, voire même ne pas compiler.
• Coder la fonctionnalité au plus simple pour que les tests fonctionnent.
• Refactorer en toute confiance, car les tests le permettent. Leur résultat ne devrait pas changer.

Lors de sa présentation, Cédric précise que l’évolution du code devrait être orientée par les erreurs de compilation : l’IDE nous aide à créer les classes manquantes. Notre but est de ne pas être noyés par les erreurs à la fin de l’écriture du test : il faut les traiter au fur et à mesure.

Le code-coverage est un indicateur important de la qualité des tests mais ce n’est pas un objectif : c’est une conséquence. En effet, si du code n’est pas testé alors le coverage n’est pas de 100%, cependant un coverage à 100% n’indique pas que le code est bien testé. Vous devriez arriver à un coverage maximum rien qu’en vous souciant de la pertinence des tests.

Beaucoup de sujets se bousculent à la fin de ce talk. Par exemple, il est fait mention des tests Inside-out et Outside-in. N’ayant pas encore assez de connaissances sur ces sujets, je me permets seulement de vous transmettre les références données en fin de talk :

• The three laws of TDD – Uncle Bob
• Non-Anemic Domain Model – Martin Fowler
• Social testing – Matin Fowler
• 80 ou 90% de couverture pour un nouveau projet ? – Colin Damon
• Type-Driven Development – Anthony Rey
• Mon apprentissage de TDD – Cédric Magne

Un développeur sous couverture parmi les utilisateurs

Ce dernier talk était incroyable ! Aurélien Boudou a travaillé pendant un an pour une entreprise familiale de scierie. Celle-ci avait besoin de reprendre à zéro leur logiciel de gestion du bois et d’estimation de prix puisque la législation avait changé (et que le développeur de l’outil précédent est mort avec l’accès au code). Contrairement à l’accoutumée, Aurélien a décidé de rompre la distance entre lui et le métier. Pour mieux le comprendre, il a été lui-même en immersion parmi eux ! Un an plus tard, le client est complètement satisfait de la prestation et les concurrents le réclament.

Outre les qualités narratives du présentateur qui rendent son retour d’expérience absolument captivant, son aventure nous laisse nous questionner sur le rapport qu’a le développeur avec le client : pourquoi avons nous besoin d’un intermédiaire ? Le PO est-il nécessaire dans une équipe constituée d‘ingénieurs capables de comprendre directement le métier ? Si les développeurs acceptaient cette responsabilité, délivrerions-nous des produits plus proches de ce que demande le client ?

La question de l’intérêt des estimations est également posée. Plutôt que d’y passer un temps trop important, pourrions-nous en passer davantage à produire ? Dans le cas d’Aurélien, le client commençait à devenir pressant. En creusant un peu, la seule information que le client voulait était : que seras-tu capable de produire pour notre date butoir ? Une macro estimation suffisait largement.

L’ensemble de ces questions sont intéressantes mais on peut rapidement y voir des limites : Aurélien est un développeur expérimenté qui a pu se débrouiller tout seul pour coder l’entièreté du projet. Quand l’équipe est plus conséquente, il peut être intéressant qu’une personne soit dédiée au recueil du besoin métier, le rôle de PO prend alors son sens. Il existe cependant d’autres organisations d’équipe où le delivery implique davantage les développeurs : les PMs donnent le cap sur la prochaine plus-value demandée et les développeurs en déduisent les développements à effectuer. Dans cette organisation, il n’y a pas de PO et les développeurs définissent eux-mêmes les évolutions qui répondront à l’objectif.

Conclusion

Victime de son succès, Lyon Craft s’est vu obligé de limiter le nombre de personnes par atelier. Il fallait alors prendre un jeton pour réserver sa place : j’ai raté de deux places l’atelier d’EventStorming. Ce n’est pas tous les jours qu’une telle opportunité se représentera. Fun-fact, à la fin de la conférence, des jeux de dames avec les dits jetons à l’effigie de la conférence ont été offerts à des spectateurs !

L’avantage d’avoir eu un plus grand succès que prévu, c’est qu’une partie de l’argent bonus a été reversée aux deux associations présentes. Etant donné la réussite de l’évènement, il est quasiment assuré d’avoir un Lyon Craft l’année prochaine. J’espère bien vous y voir !