La communauté ̶d̶e̶ ̶l̶’̶a̶n̶n̶e̶a̶u̶ eskerienne à Devoxx 2022 — épisode 2

Cet article est le second d’un publication en deux parties. Cliquez ici pour la partie 1

Esker était présent pour la dixième édition de Devoxx à Paris. Pour cette édition spéciale, les organisateurs ont mis les petits plats dans les grands et ont assuré une logistique et un planning sans faille !
Nous n’étions pas moins de 5 à aller de conférence en conférence, mais ce n’était pas suffisant pour pouvoir suivre les 8 présentations qui avaient parfois lieu en même temps ! Voici donc nos impressions sur ce qui nous a le plus marqué.

Dans cette seconde partie, Alexandre, Maxime et Edern ont le clavier. Ils sont tous les trois membres de la même équipe dont le rôle est de travailler sur le cœur de la solution SaaS Esker afin d’en assurer la performance, la scalabilité et la stabilité.

Les conférences que nous avons préférées

Alexandre & Edern : Les lois universelles de la performance

Rаphaël Luta, Solutions Architect & Data Engineer chez Apitwan

Raphaël Luta, consultant sur les problématiques de sécurité et de performance des applications a présenté quelques lois de performance qui s’appliquent à la plupart des systèmes applicatifs. Il a montré comment on peut modéliser notre application pour en déduire, à partir de mesures assez simples, son comportement en fonction de paramètres principaux tels que le parallélisme. On peut grâce à ces mêmes lois identifier le fonctionnement “normal” de notre application donc définir des valeurs suspectes pour nos métriques d’alertes. Enfin, on peut s’en servir pour prévoir le dimensionnement optimal du système sur lequel va tourner notre application.

Nous avons trouvé la présentation accessible pour un sujet qui peut être très complexe ! Nous sommes tous les deux membres d’équipes au cœur de notre produit, Esker On Demand, et une partie importante de nos missions tourne autour des problématiques de performance. En effet notre produit traite plus d’un million de documents par jour et c’est un vrai challenge de le faire continuellement “passer à l’échelle”. Nous sommes repartis de cette présentation avec des idées plein la tête pour modéliser et améliorer la performance de notre application du point de vue “macroscopique”.

Maxime : En quête du Clean Code avec Sonar, 20 000 lieues sous un océan de code !

Claire Villard, Backend Developer & Nicolas Peru, Head of Product Delivery chez SonarSource

Nicolas Peru et Claire Villard ont partagé leur retour d’expérience suite à la mise en place du clean code chez Sonar, en exploitant les outils qu’ils commercialisent.
Le clean code est un principe de développement qui a pour but de rendre le code lisible, simple à modifier, étendre et maintenir, compréhensible par n’importe quel développeur qui se plongerait dedans. Les règles sont différentes pour chaque entreprise (voire même chaque équipe), mais elles définissent un ensemble de conventions de design, de nommages, de structure du code et des commentaires.
Le constat chez Sonar est simple, la qualité du code a une forte influence :

• sur le développeur lui-même : avoir à faire de l’archéologie pour modifier le moindre détail et aborder un bug ou une feature en sachant d’avance que l’on va au devant de gros ennuis est fortement démotivant. Par ailleurs travailler avec un code de mauvaise qualité a un impact sur le sentiment de responsabilité qu’a le développeur sur celui-ci. Enfin cela peut rendre plus difficile l’onboarding de nouveaux arrivants.
• sur la maintenabilité et les coûts : le clean code réduit fortement le temps de développement et donc d’ajout de nouvelles features.
• sur le focus de l’équipe : au lieu de discuter de détails techniques, de comment on va pouvoir refactorer le code, etc., on peut se concentrer sur les vrais problèmes c’est-à-dire les objectifs que l’équipe ou l’entreprise cherchent à atteindre.

Ces sujets nous touchent chez Esker puisqu’étant une entreprise avec une longue histoire, nous pouvons être confrontés à la fois à des modules très récents et propres mais aussi à du code legacy. La promesse du clean code est de résoudre ces problèmes. Sonar permet de les identifier en les divisant en 3 catégories :

• les code smells : mauvaises pratiques, code peu clair, peu lisible
• les bugs
• les vulnérabilités

Pour identifier et corriger ces problèmes les outils Sonar proposent des profils de base pour chaque langage avec un ensemble de règles basiques, mais qui peuvent être personnalisées pour en ajouter selon les besoins de chacun ou les rendre plus strictes.

Le plus souvent, ces outils ne sont pas mis en place dès le début du projet, donc au premier lancement de Sonar, une montagne d’erreurs est signalée aux utilisateurs. D’après les speakers, s’attaquer tête baissée aux problèmes n’est pas une bonne stratégie. Cela peut casser des fonctionnements existants, les commits ne seront pas clairs, pas attachés à une fonctionnalité particulière et sans ROI côté produit pour le client.

Ils nous conseillent plutôt le principe du Clean as you code. L’idée est de considérer que le code évolue dans le temps. Le code existant bouge au fur et à mesure des développements : le nouveau code pour les nouvelles fonctionnalités respectera directement les principes du clean code, les changements dans le code existant (pour corriger un bug ou autre) sont l’occasion de modifier localement le code en respectant les règles mises en place avec les outils Sonar. D’après leur estimation, environ 20 % du code existant est modifié en un an, 35 % en 2 ans et 50 % en 5 ans. Le clean code se répand naturellement dans tout le code au fil du temps. En revanche, si le code fonctionne et n’est pas modifié, il n’est pas conseillé de le modifier. Si le code n’est pas modifié, le développeur n’est pas en souffrance pour le maintenir, le clean code n’est donc pas nécessaire à court terme.

Il est important d’affiner le “quality profile” au fur et à mesure que la pratique du clean code augmente. Commencer avec des règles peu restrictives pour éviter la montagne d’erreurs dès le début est une bonne idée, mais il faut aussi devenir plus exigeants pour augmenter la qualité du code au fur et à mesure que l’on apprend à faire du code clean. Les outils Sonar proposent des notes alphabétiques (A,B,C), qui permettent de commencer avec des critères d’acceptance faibles (note C par exemple) puis progressivement migrer vers du A. Il est aussi possible de paramétrer avec des nombres arbitraires critiques (au maximum X bugs détectés, au moins X% de code coverage, …)

Le dernier point abordé est le “quand”. Quand faire l’analyse du code ? Leur réponse est d’analyser le code le plus TÔT POSSIBLE, et tout est mis en œuvre chez Sonar pour faciliter celà. L’analyse au push est le plus courant, c’est pourquoi des plugins Sonar sont disponibles à l’image des Github actions que nous utilisons chez Esker. Mais ils vont plus loin (plus tôt ?) en intégrant des plugins dans les IDE avec SonarLint (donc avant même le commit). Le feedback “live” permet de traiter les problèmes au plus tôt, avant même le commit, et les équipes Sonar ont aussi remarqué que les développeurs prenaient de bons automatismes au fur et à mesure des développements grâce à ce feedback instantané.

Le mot de la fin portait sur un point fondamental qui est d’éviter les règles générant des faux positifs. Cela engendre une perte de temps (il faut analyser le bug remonté pour savoir s’il est légitime) et une perte de confiance dans l’outil à long terme (ce qui mène à ignorer les erreurs).

Toutes ces pratiques peuvent être mises en place chez Esker (et le sont même déjà dans certaines équipes) afin d’augmenter la qualité du code. En effet, dans une énorme base de code, il est important d’appliquer les principes de clean code pour réduire au plus tôt les bugs ou code smells, mais de le faire de manière progressive pour éviter d’être noyé sous les rapports de Sonar. La mise en place du clean code permet aussi de faciliter l’intégration de nouveaux collègues, qui s’y retrouveront plus facilement.

Alexandre & Edern : Mob programming, la véritable approche du développement en équipe

Maxime Odye, développeur backend et Mathieu Pousse, Lead Developer chez Ouest France
Comment réagirait votre manager s’il surprenait toute l’équipe de développement autour d’une même machine ? Après des comparaisons douteuses avec la DDE, Maxime Odye et Mathieu Pousse sont revenus sur l’expérience du “mob programming” dans leur équipe chez Ouest-France depuis plusieurs années. Avec respectivement 1 et 5 années d’expérience sur le produit, ils ont pu nous offrir des points de vue variés et complémentaires.

Le mob programming, ou programmation en groupe, est une extension du pair programming, qui consiste à rassembler toute ou une partie de l’équipe autour d’un unique écran et clavier d’ordinateur. Cette technique s’appuie sur le Lean et sur Extreme Programming. Il est même possible que vous en ayez déjà entendu parler, car ce concept a commencé à faire parler de lui au début des années 2000, notamment suite à la parution de différents ouvrages traitant de l’Extreme Programming. Au final, toutes les réunions, qu’elles soient dédiées à la conception d’un produit, ou à la direction d’une entreprise, pourraient donc s’apparenter à cette technique, dès lors qu’elles rassemblent un groupe de personnes travaillant ensemble sur une même problématique.

Les avantages sont divers. Le principal étant le partage. Notamment le partage des pratiques, des outils, de l’histoire du projet, de son code et de son écosystème. Ceci amenant à une montée en compétence des participants. Le fait de travailler en groupe permet également d’exploiter l’intelligence collective, avec pour résultat une augmentation de la qualité de la solution et un gain en efficacité. Par ailleurs, en partant de l’idée que chaque individu a son pic de performance à différents moments de la journée, le travail de groupe permettrait de conserver une bonne efficacité tout au long de la session de mob programming.

Enfin, tous ces moments passés ensemble permettent également d’augmenter la cohésion d’équipe. Les réunions de synchronisation (ou stand-up dans les méthodes Agiles), ainsi que les revues de code ne sont plus nécessaires.

A l’inverse, les inconvénients seraient bien moins nombreux. Le principal étant l’indisponibilité de l’équipe, se retrouvant injoignable, isolée dans une salle dédiée à cette pratique. Même si cela peut être pallié par un dispositif permettant de les joindre, les interruptions sont nuisibles au bon déroulement de la session de mob programming.

Avec tous ces avantages et très peu d’inconvénients, cette méthode, bien que controversée, semblerait donc particulièrement prometteuse. Pour autant, sa mise en pratique peut-être semée d’embûches. C’est pourquoi les présentateurs ont jugé important de revenir sur leurs échecs, tout en nous encourageant à essayer par nous-même, sans avoir peur de nos propres échecs, parfois nécessaires. Parmi les causes pouvant impacter le bon déroulement de cette pratique, nous pourrons retrouver par exemple :

• le manque de préparation, amenant à une perte de temps.
• des sujets non adaptés, qu’ils soient trop simples, trop pointus, ou trop ambitieux
• une dérive des discussions vers des débats philosophiques ou tout autre sujet ne faisant pas partie du périmètre du mob
• le mode hybride, avec des personnes en présentiel et d’autres en distanciel.

Une des difficultés de cette pratique repose également dans la capacité à trouver un rythme adapté à tout le monde, ni trop lent, ni trop soutenu. Les participants devront réussir à s’adapter aux autres, accepter leurs vitesses de frappe sur le clavier et leurs façons de s’exprimer. Attention à ne pas tomber dans le piège de la saisie en parallèle qui est à proscrire. Les sujets ayant des dépendances à des ressources externes, pouvant casser le rythme, sont également à éviter.

Fort de cette expérience, un ensemble de conseils a pu nous être présenté. Tout particulièrement, le choix des sujets que l’on souhaite traiter en mob programming est primordial. Il devra concerner tous les participants, ne pas être trop rébarbatif et apporter une forte valeur ajoutée. L’objectif à atteindre devra retenir l’intégralité de l’attention des participants. Si un besoin alternatif apparaît, il devra être noté de côté sur le gestionnaire de tâches de son choix, afin d’être traitée ultérieurement. Par ailleurs, la mise en place d’un rituel, une date récurrente à laquelle se déroulera la session de mob programming peut aider à l’instauration de cette pratique. Enfin, la sécurité psychologique au sein de l’équipe est un atout déterminant, permettant notamment la mise en place de “la règle des deux pieds” : à tout moment, les participants doivent avoir la liberté de quitter la réunion, quelles qu’en soient les raisons.

En fonction des équipes, cette manière de programmer pourrait donc paraître disruptive, avec tout de même pas mal d’obstacles pour les équipes qui franchiraient le pas. Mais le gain général en productivité, difficilement quantifiable, semble bien présent ; Maxime et Mathieu en sont convaincus. Et vous, seriez-vous prêt à expérimenter cette technique dans votre équipe ?

Les conférences qui nous ont le plus surpris

Nous n’y allions pas avec des attentes particulières, mais certaines conférence se sont révélées particulièrement intéressantes !

Edern : Github Co-Pilot : Addictif ou Efficace ?

Johan Jublanc Head of data & Simon Provost, Data Engineer chez LittleBigCode

Pour ma part, la conférence qui m’a le plus agréablement surpris concernait Github Copilot. Cet outil qui a fait pas mal parler de lui récemment, se targue de vous assister dans votre développement en prédisant le code que vous voulez écrire et en vous proposant parfois jusqu’à une fonction entière. Pour cela, l’“IA” s’inspire fortement de tout le code public sur Github.

Appuyant leur propos sur des démonstrations en direct, Johan Jublanc et Simon Provost ont fait le bilan de leur utilisation de l’outil.
Côté avantages, ils notent qu’il est efficace, permet de découvrir des bibliothèques, permet d’explorer plusieurs options et provoque régulièrement des “effets waouh” après qu’il aient seulement écrit un début de ligne, de commentaire ou de nom de fonction.
Côté inconvénients, ils notent que les suggestions ne sont pas forcément optimales voire vraiment mauvaises dans le cas de librairies peu utilisées. Par ailleurs, plutôt orienté script, l’outil est incapable de prendre en compte le code existant en dehors du fichier courant et se perd si on modifie du code plus haut dans notre fichier.

Au final, l’outil reste pour eux très utile mais uniquement pour la création initiale d’un code à partir de rien. Par ailleurs, son principe de fonctionnement même pose des problèmes en suggérant des fonctions potentiellement dépréciées, des mauvaises pratiques répendues, et en général du code pas forcément maitrisé (voire des identifiants publics par erreur ?).

Maxime : Fuzzing en Go

Valentin Deleplace, Happy Path Engineer chez Google

Une conférence qui m’a particulièrement surpris est celle concernant le fuzzing en Go. Je connais le Go de loin, ce langage moderne dont tout le monde parle depuis quelques années mais que je ne pratique pas personnellement ni professionnellement. Je connais également le principe de fuzzing, l’envoi automatique d’entrées semi-aléatoires afin de tester un programme, souvent utilisé par les ingénieurs développeurs soucieux de la sécurité du programme ou même certains reverse-engineers.
A Devoxx, Valentin Deleplace souhaite nous parler de la distribution Go 1.18 toute fraiche et plus particulièrement de l’ajout natif du fuzzing.
En effet, Go embarque dans sa bibliothèque standard le package test qui permet très simplement de tester son programme. Il revient d’abord sur l’ensemble des sous commandes disponibles :

• go test pour les tests unitaires
• — cov pour le code coverage
• — profile et — bench pour l’analyse des performances et de la mémoire du programme
• — trace pour écrire une trace d’exécution avec l’utilisation CPU
• — race pour les race conditions
• — fuzz la nouveauté en 1.18 et focus du talk, pour lancer des tests avec input semi-aléatoire

Plusieurs démos de Valentin nous ont permis de voir la puissance du tooling natif en Go mais également du fuzzing, qui offre la possibilité de tester encore plus profondément le code (comparativement aux TU qui sont des cas spécifiques pensés par le développeur) et de filtrer les bugs en amont de la livraison.
Le fuzzer est très rapide et sort un rapport en cas d’erreur. Il est également “intelligent”, il va regarder le code coverage des exécutions précédentes pour essayer d’aller plus loin dans le code à chaque nouvelle exécution. Il est possible de lui donner des “hints” pour le guider sur le type d’input que le programme attend.

Développeur en C++ chez Esker, habitué aux tests unitaires classiques et le plus souvent à des tests automatiques plus haut niveau, plus fonctionnels, comment ne pas être impressionné par la diversité et la puissance du tooling natif d’un langage moderne comme le Go?

Le mot de la fin

Voilà qui conclut notre best-of de Devoxx 2022 ! Cette édition était réussie sur tous les points avec des conférences intéressantes, des exposants sympathiques et une organisation bien huilée. Nous en revenons avec plein d’idées pour la R&D d’Esker et sommes pressés d’y retourner lors d’une prochaine édition !

Pour revenir à la première partie de cette publication, cliquez ici !