Lyon Craft 2024 : retour sur 7 conférences

Qu'est-ce que le Lyon Craft ?

Le Lyon Craft, c’était une journée et un endroit pour partager et confronter les différentes expériences liées à la pratique du Software Craftsmanship.

L’événement est organisé par des piliers de la communauté du Craft, dont Colin Damon (de la société Ideme), tout comme le XCRAFT qui avait eu lieu quelques mois auparavant. Toute personne intéressée ou intriguée par le Craft a sa place ici, il y aura toujours une conférence qui justifiera le déplacement.

Il a eu lieu à l’Embarcadère à Lyon, le lundi 8 avril, sur plusieurs salles dans lesquelles nous pouvions assister à des conférences plus ou moins participatives mais aussi à du livecoding ou des ateliers de groupe.

Qu’est-ce que le Software Craftsmanship ?

Le Software Craftsmanship est un état d'esprit, une approche qui met l'accent sur la qualité du produit et du code, une conception bien pensée pour les produits, et une attention particulière aux relations humaines dans le cadre du travail. Les conférences de cette journée mettent l'accent sur un ou plusieurs de ces aspects.

Retour sur quelques conférences

Grégory, Analyste Programmeur Back-end chez Extia Lyon, s'est rendu début avril 2024 au LyonCraft et nous partage ce qu’il a retenu des conférences auxquelles il a pu assister. Entre Architecture Hexagonale, Software Crafting, Trunk Based Development ou encore le Biomimétisme, vous allez être servis !

L'architecture hexagonale autrement par Julien Lenormand

Cette conférence est faite pour vous si vous souhaitez voir comment un besoin basique peut progressivement se transformer en un projet utilisant une architecture hexagonale. Retrouvez la vidéo de la conférence ici.

La conférence était centrée sur la vulgarisation de l'architecture hexagonale à travers un atelier de live coding, durant lequel nous avons progressivement intégré cette architecture. Le cas d'usage présenté était le suivant : dans le cadre du projet, il était nécessaire de récupérer des données d'un live bucket pour connaître l'état des PR (Pull Requests, branches de développement adressant un besoin et dont on demande l'intégration dans le projet principal).

Les premières versions adressent le besoin de manière basique :

1. vue globale des PR : tous les Users
2. vue spécifique user des PR, on ajoute un filtre sur les données
3. le meilleur des deux mondes : contenu non filtré ET contenu filtré

Les versions suivantes regardent plus loin que le besoin basique. 4. rendre testable le produit

On ajoute des fonctions pour charger des fichiers de tests, on gère de nouvelles visualisations, on teste des contrats d’interface, etc.

La version finale, développée en collaboration avec les suggestions du public, reflète les principes de l'architecture hexagonale.

Rester Zen en codant avec Léa Coston & Matthieu Sauboua-Beneluz

Cette conférence est faite pour vous si vous souhaitez découvrir divers modes de pensée en action et apprendre comment des gestes simples peuvent rendre le code plus compréhensible et maintenable. Retrouvez la vidéo de la conférence ici.

Lors de l'Advent Of Code, un événement de code sur les 25 premiers jours de Noël, Léa a eu un problème sur un des exercices : elle n'arrivait pas à développer le code nécessaire pour résoudre l'énigme. Elle a appelé Matthieu, qui pratique le Software Crafting. Voici quelques highlights de la conférence.

Quand on travaille sur un problème à résoudre, comme créer une fonction ou un algorithme pour adresser un besoin, on y met de la concentration. Certains éléments peuvent rendre la concentration plus difficile ou plus coûteuse :

• la charge cognitive : ce qui est lié à la tâche, ou ce qui est lié au contexte extérieur
• la mémoire de travail : on ne peut garder qu'un certain nombre d'éléments en tête.
• le manque de recul sur son travail

Comment peut-on se simplifier la vie ?

• En nommant les fonctions et variables de manière explicite pour comprendre leur utilité : évitez les termes génériques comme truc, machin ou var, et utilisez des noms précis comme tableaux, rangées, sections, sous-chaînes, bâtiments, meubles, opérateurs téléphoniques, etc.

• Si un bout de code est très compliqué à appréhender : il faut l'isoler et le tester unitairement. Si le fonctionnement est incorrect, il ne faut pas occulter des pans de code sous prétexte que "ça, ça marche".

• En explicitant son intention au plus tôt : réduire la pile d'instructions en créant des fonctions (bien nommées) qui prennent en charge une responsabilité unique, et se rappeler quel est l'objectif à atteindre (quel est le but de l'algorithme ou de la fonction ?).

Trunk based development avec Romain Koenig

Cette conférence est faite pour vous si vous souhaitez comprendre pourquoi un projet devrait passer de fonctionnalités complexes et difficiles à gérer à des modifications moins impactantes, offrant ainsi une meilleure réactivité pour l'équipe et une satisfaction et confiance pour les parties prenantes. Retrouvez la vidéo de la conférence ici.

Objectifs : merger des PR (pas trop longues), au lieu d'avoir des branches de développement à la vie très longue et difficiles à réintégrer dans le projet une fois arrivées à maturité

Si les PR sont trop longues, quels sont les désavantages ?

• les développeurs traînent les pieds : fastidieux à maintenir, fastidieux à transmettre, démotivation en hausse
• le stress lors de la mise en production (MEP) : enjeux importants, beaucoup de probabilités et d’erreurs bloquantes
• PR difficile à reprendre : pour l'auteur originel après une pause, et pour un repreneur si c'est une transmission de projet.

Donc la proposition est la suivante :

• Short Lived Feature Branch : branches à petite durée de vie
• Découpage fonctionnel : enlever le Nice To Have, ne garder que ce qui a de la valeur
• Découpage technique : séparer les commits, ne pas avoir de dépendances entre eux

Quelques-uns des principes à l’oeuvre dans le projet :

• Feature flags : la fonctionnalité est poussée en production, mais désactivée par défaut. Elle pourra être activée sans refaire de MEP, au moment où le métier le voudra.
• A/B testing : on propose à une population d'utilisateurs la feature A, à une autre la feature B, on fait une campagne de tests, on compare, et on conclut (exemple : fonctionnalités de Gmail).
• Flags spéciaux (exemple du Black Friday) : on déclenche un mode spécial pour l'application en cas de grosse affluence, prévue ou constatée, et retour au mode normal par la suite.

Dans cette organisation, tout changement structurel au projet est documenté par un ADR (Architecture Decision Record). Elle fait l'objet d'une PR qui doit être validée par l'équipe. Ironie, la première PR pour passer à un mode "trunk based" a été retoquée par l'équipe : elle était trop longue ! La seconde version est allée à l'essentiel et a été acceptée.

Viens on fait un talk ! avec Houleymatou Baldé & Colin Damon

Cette conférence est faite pour vous si vous n'avez jamais envisagé de devenir speaker pour un talk ou une conférence, ou si vous pensez que votre expérience ne contient rien d'intéressant à partager (spoiler : c'est FAUX). Retrouvez la vidéo de la conférence ici.

Ce talk ne porte pas sur un sujet technique. C’est plus une pièce de théâtre qui s’est déroulée sous nos yeux.

Le sujet ? Colin, organisateur du LyonCraft et du Xcraft, tente de convaincre Houleymatou, cofondatrice de Yeeso et non-technique, de venir faire un talk au LyonCraft 2024.

Au fil de la discussion, Houleymatou expose toutes les raisons pour lesquelles elle pense ne pas être en mesure de faire ce talk ou de ne pas en être légitime. Colin, quant à lui, répond à chacune de ses objections et l'encourage avec conviction.

Conseils pour faire un talk :

• Partir d’un exercice ou exemple simple (exemple dans ce cas : leap year, ou comment déterminer si une année est bissextile ou pas ?)
• Utiliser les compétences que l’on a : si on sait faire des dessins, les utiliser et en mettre plusieurs
• Engager le public en le faisant participer : questions ouvertes ou fermées, mains levées
• Si vous avez des facilités à l’oral, jouez-en !
• Si vous savez chanter, faites-le !

Finalement, Houleymatou aura déroulé un sujet complet et double : modéliser un kata de leap year, tout en montrant qu’elle a fait le talk que Colin lui avait demandé.

Vous n'avez pas besoin d'être expert sur un sujet pour en parler. Si vous y avez consacré deux heures, c'est souvent deux heures de plus que la plupart des gens, ce qui vous rend plus connaisseur de ce sous-domaine. Beaucoup de personnes se posent des questions à ce sujet et seront intéressées par votre retour d'expérience, en repartant plus informées et aguerries.

Si vous voulez aborder un sujet technique sans être dans la technique :

• Parlez du contexte, de l'humain, ou proposez une approche de vulgarisation.
• Invitez un expert technique pour traiter cet aspect et présentez le sujet en binôme, comme l'ont fait Colin et Houleymatou

DDD et product, piliers d'une transformation craft avec Damien Carbonelli

Cette conférence est faite pour vous si : cela vous intéresse de savoir comment un projet monolithique de grande ampleur introduit du craft dans son fonctionnement et se dirige vers une archi plus orientée sous-domaines. Retrouvez la vidéo de la conférence ici.

Dans le contexte métier d’un projet RTE (Réseau de Transport d’Electricité), il est question d’un projet où l’on monitore l’offre et la demande en énergie. Le projet LinkySup en traite des millions par jour. Le SI est très complexe, les équipes sont spécialisées, dépendantes les unes des autres, et peu autonomes. Il fallait changer.

Déconstruire, factoriser, anticiper, prendre du recul. Le domaine monolithique et complexe a été fractionné en une vingtaine de sous-domaines. La volonté affichée était d’aller au plus près d’”accelerate”, ou “XLR8” : se baser sur les capacités d’une entreprise pour augmenter la valeur qu’elle délivre. Plus d’infos détaillées ici.

Sur les 22 modules (domaines), on commence par celui qui est peu utilisé ou mal valorisé/ On y gagne deux fois :

• une partie de l'application gagne en clarté et en maintenabilité
• une partie peu utilisée ou valorisée peut ainsi prendre la lumière et gagner en usage

La Living Doc est utilisée : la documentation est générée automatiquement à chaque MEP et reste à jour. On peut voir les différences entre les versions et repérer les soucis dès leur apparition.

Avec les principes évoqués plus haut et quelques autres, les développeurs sont plus actifs et impliqués, et les bugs détectés sont corrigés plus vite et sont moins impactants.

Une architecture pour tester son front end par Alexia Souvane

Ce talk est fait pour vous si vous pensez qu’on ne testait que le back-end d’une application et jamais le front-end, vous aimez le live coding qui marche, vous vous dites que tester le front-end c’est forcément avec Selenium. Retrouvez la vidéo de la conférence ici.

Tester son code est nécessaire.

La pyramide de tests se présente généralement ainsi : Peu de tests End-to-End (E2E) car c’est coûteux à mettre en place, et sécurisent les processus critiques de l’application Tests d’intégration : il y en a plus, ils testent des parties applicatives en suivant les actions métier Tests unitaires (TU) : tester en isolation des parties atomiques de l’application pour s’assurer de leur bon comportement. Ce sont les tests les plus nombreux et les moins chers.

Cela marche bien pour le back-end. Mais pour le front-end, comment tester une IHM ? Une interface ?

On veut tester les comportements, pas l'implémentation. L’idée est la suivante : on va lancer pour un test front-end, un contexte initial puis une action, et vérifier à la fin que le système est dans l’état attendu.

Pour arriver à faire ces tests, il faut :

• isoler l'unité de code qui met à jour la donnée
• éviter le couplage des parties métier avec le framework, sinon impossible de tester des parties indépendantes
• augmenter la cohésion : tous les éléments d’un même module ont un même but Le tout nous a été expliqué dans le contexte d’une to do list, et avec un refactoring en live étape par étape.

Plus de détails sur les principes de couplage et de cohésion ici.](https://anuragbisht12.medium.com/cohesion-vs-coupling-in-software-design-patterns-5154f6db4148)

Le biomimétisme au secours des dev avec Christophe Breheret-Girardin

Cette conférence est faite pour vous si vous voulez explorer le champ des possibles et ouvrir votre esprit. Retrouvez la vidéo de la conférence ici.

Cette conférence traite beaucoup de sujets : voici quelques points qui m’ont marqué.

On peut apprendre beaucoup en travaillant.

Exemple du biomimétisme : le Shinkansen, train ultra rapide au Japon, a été conçu et profilé à partir des observations du martin-pêcheur, oiseau qui peut rentrer dans l’eau et en ressortir en créant très peu de perturbations dans l’eau, ce qui est intéressant pour aller plus vite avec moins d’énergie dépensée. De la même manière, certains panneaux solaires sont tournants pour avoir une exposition maximale au soleil selon l’heure de la journée : cela est inspiré des tournesols. Ce ne sont pas des sujets directement techniques ou informatiques, mais ils ont des répercussions sur nos technologies.

Le code c'est comme une blague : si on doit l'expliquer, c'est qu'il n'est pas bon.

Le figuier étrangleur

L’idée est d’utiliser des remplacements locaux progressifs pour au fur et à mesure, changer des parties applicatives jusqu’à ce que les nouveaux développements soient l’application et que l’ancienne ait disparu, comme le figuier étrangleur avec l’arbre qu’il parasite. Pour faire cela, on utilise des façades, on double les écritures, on use et abuse du feature flipping pour pousser les nouveaux éléments en production et ne les activer que lorsqu’on en a besoin.

La méduse immortelle

Le cycle est le suivant : l'application évolue, atteint une refonte, repart de zéro, et le cycle recommence. Comme la méduse qui a un moment entre en léthargie, et après une longue période, revient en activité comme si elle avait rajeuni. Pour casser ce cycle, investissez sur la qualité.

Les tests pastèques

Pour avoir de bons KPI, on crée des tests inutiles pour augmenter la couverture. Ils sont verts dehors, rouges dedans. Exemple : une fonction de calculatrice entièrement couverte mais qui ne teste pas la division par zéro

La diversité de la prairie

SI une application modélise la prairie, est-ce pertinent que herbe et fleur implémentent strictement les mêmes méthodes ? Ne pas forcer l'herbe à implémenter l'odeur. Ne pas forcer une classe à implémenter des méthodes inutiles.

N'imitez pas pour imiter

Ne prenez pas dans la stack de votre nouveau projet la dernière technologie à la mode pour le plaisir d’être à la pointe. Privilégiez des technologies éprouvées. Ne donnez pas de la matière à "la guerre des moutons".

D’autres conférences ont eu lieu ce jour-là : parcourez les playlists pour voir si des conférences peuvent également susciter votre intérêt. Si le titre vous parle, soyez curieux.

Pour aller plus loin :

Sources : Playlist de la salle principale (Halle) Playlist de la salle Pause & Play Un thread sur Linkedin

Quelques supports de conférence : Rester Zen en codant Retour d'expérience sur le UnConf, la journée suivante du LyonCraft. Le UnConf permet de debriefer les conférences du jour précédent et de faire des ateliers aux formes assez inhabituelles.

  Cet article a été rédigé par Gregory, Développeur Back-End chez Extia