Apprendre et se perfectionner durant AlpesCraft
En ce début du mois de juin, une partie de notre équipe de développement (Gwenaël, Renaud et Marc) a participé à la conférence « AlpesCraft » à Grenoble. Un moment d’apprentissage et de partage pour progresser et contribuer à rendre notre SIRH meilleur. Voici notre debriefing de cette jeune conférence, riche d’inspiration et d’apprentissage.
Des conférences inspirantes
« Keynote - eXtreme Programming : LA méthode Agile ? »
Une première session avec Pascal Le Merrer pour se mettre en jambe et (re)découvrir la méthode ex, une des premières méthodologies agiles, pourtant peu pratiquée. C’était très inspirant de commencer la journée par se recentrer sur le fait de mettre en place des pratiques d’excellence au niveau « technique », comme moyen de développer de meilleurs logiciels.
Event Storming par la Pratique
Une vraie découverte pour nous de cette notion. Grâce à l’énergie de Nicolas Savois, nous avons pu nous mettre dans la peau d’une équipe concevant un challenger à l’application « Meetup », et voir émerger en quelques dizaines de minutes la « big picture » des fonctionnalités et du flux d’information de notre projet.
Applicable autant en reverse-engineering sur des systèmes existants (pour onboarder une nouvelle personne, ou aligner les connaissances dans une équipe), que pour concevoir les grandes lignes d’un nouveau système, la méthode a tapé dans l’œil de Marc, notre CTO : « J’ai très envie de l’utiliser pour démarrer un de nos prochains chantier fonctionnel »
Always-Green Refactoring : Retravailler sa codebase en douceur et sans stress
Au croisement d’un partage de bonnes pratiques et d’une présentation de la méthode Mikado, cette présentation assortie d’un live Coding par Thomas Carpaye et Mohammed Lamzira nous a emmené sur des terres connues. Pas de grandes révolutions pour nous, mais l’on est reparti avec des petits tips pratiques sur comment faire de petits pas dans le refactoring, en ayant toujours une application fonctionnelle (fini l’étape de refacto de 30minutes qui casse 10 fonctions dans le code).
L'Escape Game du Legacy. Patterns et Stratégies pour maintenir l'existant / De code legacy à l'archi hexagonale - immersion dans l'univers du mob programming
Deux sessions sur le mob-programming auxquelles nous avons assisté pour confronter les pratiques que nous avons dans l’équipe. Une première session avec Christophe Thibaut et son « escape game », parfois perturbant par le nombre de participants (mais c’était une belle expérience sociale).
Nous en retenons que dans le MOB, il faut avoir conscience que l’on aura différents profils de développeur :
- Ceux qui veulent corriger ou faire l'évolution directement
- Ceux qui veulent écrire une couverture de code complète avant de commencer
- Ceux qui veulent relire et comprendre le code existant
Avec ces différences, il faut arriver à faire le compromis entre se mettre tous d’accord, et avancer moins vite, ou alors choisir un cap à un moment et s’y tenir (sans oublier de quand même dézoomer de temps à autre pour valider la pertinence de notre direction).
La pratique de la chaise libre qui permet à n’importe quel participant du MOB de prendre la place du navigateur nous a semblé intéressante, même si dans les MOB à 3 ou 4 personnes que nous pratiquons dans l’équipe, nous aurons probablement peu de chance de la mettre en place. Nous avons pu compléter cette comparaison de pratiques avec la session de Caroline Desplanques et Pauline Jamin, dans laquelle nous avons redécouvert l’outil mob.sh que nous avions déjà expérimenté dans l’équipe. (et nous avons justement un sujet traité en mob cette semaine dans lequel il a été réutilisé).
L’Intégration Continue en Quatorze Pratiques
Dans cette session, Thierry de Pauw nous a emmené dans le monde de l’intégration continue, à travers 14 pratiques.
Voici les points qui nous ont marqués, et pour lesquels nous allons voir avec l’ensemble de l’équipe comment les mettre en place :
- La CI doit tourner vite (idéalement entre 5 et 10 min)
De notre côté, on est autour des 10 min, mais avec certains tests déportés la nuit - On doit pouvoir lancer en local le même script d’intégration que sur la CI
C’est le meilleur moyen de détecter les problèmes au plus tôt, et de ne pas casser le build commun. Là encore c’est plus facile quand un build est court.
Une alternative que nous avons déjà sur un de nos projets est de faire tourner la CI sur les branches de feature. - Si un test dure + de 1seconde, il faut le retravailler
Assez logique si l’on veut accélérer le build global, il faut que chacun des tests soit suffisamment petit - Si on casse la CI, on répare dans les 5 minutes, ou alors on revert.
- Les tests doivent être indépendant au maximum (de la BDD par exemple)
Moins on a d’adhérence avec l’infrastructure, plus les tests sont rapides - Lancer tous les types de tests à chaque intégration (Compromis avec le temps, mais normalement on doit pouvoir tous faire)
Cf le point 1, nous sommes actuellement dans ce compromis d’avoir dû déporter certains tests pour garder une CI rapide - Ne jamais pousser sur un build rouge. Cela permet de ne pas empiler des problèmes, et de ne plus pouvoir trouver la cause. Cela se rapproche aussi de la théorie de la vitre brisée. Si notre CI est instable, ou trop souvent rouge, on ne s’alertera plus en cas de réel problème.
En conclusion
Un grand merci à tous les speakers pour leur partage de connaissance, et aux organisateurs pour avoir permis cette belle journée. Ce fut une journée riche en apprentissage. Quelques découvertes mais surtout beaucoup de confirmation de la pertinence des pratiques mises en place au fil de l’eau dans l’équipe.
"Ce sont des pratiques que nous appliquons au quotidien, ces échanges nous ont permis d'aller plus loin dans la démarche pour faire évoluer le fonctionnement de l'équipe" Gwenaël