On a tous déjà entendu dire de la part d’un développeur: “Ce code est illisible”, “c’est écrit avec les pieds” ou “$#@!, si je l’avais fait à partir de zéro ça aurait été plus rapide”. Et si vous avez déjà développé, vous avez déjà eu cette impression d’être dans Indiana Jones à devoir déchiffrer des écrits anciens, sans oser toucher à telle ou telle partie au risque de déclencher un piège et tout faire s’effondrer. Ce monstre incompréhensible, illisible et non maintenable c’est l’héritage qu’un développeur laisse à ses successeurs, qu’on appelle le “Legacy Code”. Il y a plusieurs définitions du legacy code, mais ce dont on parle le plus souvent c’est de ce code illisible repris par un développeur qui n’en est pas l’auteur. Ce code que l’on va modifier sans savoir si on a changé tout son comportement et qui va nécessiter toute une série de tests pour vérifier que toutes les fonctionnalités continuent de fonctionner correctement.

Vous l’avez compris, toute la difficulté est de produire un code qui pourra être facilement maintenu et qui pourra évoluer dans le temps sans que cela en coûte trop d’efforts au développeur qui récupère l’héritage.

Ce que l’on va démontrer via l’atelier qui suit, c’est l’importance de la base du code qui sera déterminante dans toute la vie du programme écrit, de sa maintenabilité et son évolutivité. Pour cela, nous allons faire un exercice qui consistera à bâtir des tours de legos en les empilant les uns sur les autres dans un intervalle fini (sprint). Petite précision: les legos vont devoir être empilés sur le côté afin de ne pas s’emboîter, sinon l’exercice serait trop simple et perdrait son intérêt.

Ce dont on a besoin pour cet atelier:

  1. Un(e) facilitateur/facilitatrice
  2. Des briques carrées de legos de deux couleurs différentes
  3. Une montre pour faire le timing des sprints
  4. Un tableau pour noter les résultats
  5. Des bonbons pour les gagnants (ce n’est pas obligatoire mais c’est toujours mieux d’avoir un prix)

Cet atelier se déroule en 5 parties différentes:

1. Chacun fait sa tour

Le facilitateur distribue des legos aux participants, et leur explique qu’ils doivent construire la tour la plus haute en un sprint de 20 secondes. Le gagnant est celui qui a construit la tour la plus haute.

L’étape se déroule en 3 sprints. A chaque fin de sprint on notera les résultats de chaque participant et on détruira les tours pour repartir de zéro pour le prochain sprint. Dans cette partie, ce que l’on souhaite démontrer c’est que chaque participant arrive à faire à chaque sprint une tour meilleure que la précédente. Plus on fait une tâche, plus on s’améliore. Mais ça peut être à double tranchant car la rapidité peut nous pousser à l’erreur. Et l’on constate dans ce cas que les tours s’écroulent plus ou sont moins stables.

Tout l’enjeu est donc de comprendre qu’il faut trouver un équilibre entre la technique et la rapidité. Plus un code sera écrit vite et moins il aura de chance d’être stable. Plus un code sera réécrit et plus il sera amélioré.

A la fin du 3ème sprint, on fait une rétrospective entre les participants pour qu’ils partagent leur expérience et leurs difficultés et réfléchissent à des axes d’amélioration.

2. Une tour colorée

On commence la deuxième partie en ajoutant une contrainte qui sera d’alterner la couleur de chaque brique posée pour construire la tour. On refait le même exercice que dans la partie précédente. Le but est de montrer qu’en ajoutant des contraintes on perd en premier lieu en efficacité, mais que si l’on réussit à s’organiser correctement, l’efficacité sera la même que la partie précédente.

A la fin du 3ème sprint, on refait une rétrospective et on demande aux participants d’exprimer les difficultés rencontrées par rapport à l’étape précédente. L’animateur peut demander aux participants ce qu’ils ont changé et ce que ça leur a permis d’améliorer.

A ce stade de l’atelier, vous pouvez annoncer le premier gagnant avec plus de points cumulés sur les deux premières parties.

3. A deux c’est toujours mieux

Pour la 3ème partie de notre atelier, on fait des groupes de deux. Petite astuce : mettez des personnes qui ont obtenu un score haut avec ceux ayant obtenu un score faible sur les précédentes parties. Cela permet d’équilibrer les groupes.

Cette fois-ci on ne fera que deux sprints. Dans la plupart des cas, si les groupes sont été équilibrés avec un fort et un faible, les forts auront tendance à prendre les choses en main et les faibles à observer.

On refait une rétrospective entre les groupes. Le facilitateur peut demander aux participants les moins actifs ce qu’ils ont ressenti et si cela leur est déjà arrivé dans la vie de tous les jours. Et enfin si c’est une pratique qu’il faut changer et comment.

Concernant les groupes qui ont travaillé ensemble : est-ce qu’ils ont eu l’impression que leur performance a baissé et comment est-ce qu’ils ont fait pour se partager les tâches ?

Le but de cette partie est mettre en lumière les habitudes de chacun concernant la répartition des tâches et du travail en équipe.

4. Co-construire

Pour cette partie, on ajoute une contrainte supplémentaire : la tour doit absolument être co-construite. Cela signifie que chaque brique de la tour doit être posée par une personne différente, et d’une couleur différente. Lancez 3 sprints et faire une rétrospective. Centrez la discussion sur la difficulté de travailler à deux et comment ils peuvent l’améliorer.

5. Legacy, oh my legacy

Pour cette dernière partie, on garde les mêmes règles à la différence qu’après chaque sprint la tour est conservée pour le sprint suivant, contrairement aux autres parties. La tour conservée représentera le legacy code. A chaque nouveau sprint, il faudra donc ajouter des étages à la tour existante. On notera les différences de hauteur entre chaque sprint au tableau (négatif si la tour perd malencontreusement des étages). Cette partie comptera 4 sprints.

A la rétrospective, le facilitateur va demander aux participants quelles difficultés ils ont rencontrées et pourquoi le résultat n’est pas égal à la somme des parties précédentes alors qu’on a conservé les tours à chaque sprint.

Le but de cette dernière partie est de démontrer que travailler sur une base déjà existante n’est pas chose aisée et qu’avec une base de tour « simple » il n’est pas possible de construire au delà d’une certaine hauteur.

Il en est de même pour un code instable qui n’a pas été sécurisé par des tests, jusqu’à un certain point il ne sera plus possible de le maintenir et de le faire évoluer sans risquer de tout détruire.

Pour la fin de l’atelier, amenez sur les améliorations possibles pour arriver à construire une tour toujours plus haute.

Si vous voulez aller plus loin et que vous disposez du matériel nécessaire, voici quelques propositions intéressantes :

  • Continuer la tour mais sur une surface plus plane et plus stable. Cela peut être associé à l’idée d’une stabilité des environnements de production et de développement. Le facilitateur peut toujours challenger ce point en ajoutant que même si ça aide, ce n’est pas suffisant.
  • Changer la base de la tour pour améliorer la stabilité, en intégrant par exemple un nouveau type de brique plus large ou plus solide. On appelle cela une refonte technique.
  • Ajouter une structure à la tour pour empêcher qu’elle ne s’effondre lorsqu’on ajoute des briques. Dans la réalité on peut traduire cela par l’ajout de tests. En ajoutant des tests on s’assure que notre code est toujours robuste et résistant malgré l’ajout de modifications.

Bonne chance et bonne construction.