La méthode Mikado

Vaincre le code legacy à coup de baguettes

Introduction

Présentation de la méthode et de son origine

La méthode Mikado tire son nom du célèbre jeu d'adresse japonais éponyme. Développée par Ola Ellnestam et Daniel Brolund, cette méthode a été introduite pour répondre aux défis de réécriture du code legacy, c'est-à-dire le code existant souvent complexe, fragile et difficile à maintenir.

L'idée est de fournir une approche structurée pour aborder la réécriture du code de manière incrémentale, en minimisant les risques et en évitant les perturbations majeures. Comme dans le jeu du Mikado, où l'objectif est de retirer les bâtonnets sans faire bouger les autres, la méthode Mikado encourage les développeurs à effectuer des modifications spécifiques sans impacter négativement le reste du code.

L'origine de cette méthode remonte à une situation courante dans le développement logiciel : lorsque les développeurs se confrontent à un code complexe et qu'ils cherchent à y apporter des modifications (tout le temps ?!), ils peuvent se retrouver face à des dépendances et des interactions imprévues entre différentes parties du code. Cette complexité rend les changements délicats et augmente le risque de provoquer des erreurs ou des effets indésirables. C'est là que la méthode Mikado entre en jeu ! Elle propose une approche itérative pour gérer ces dépendances complexes et minimiser les impacts indésirables. Plutôt que de plonger directement dans la réécriture du code, la méthode Mikado encourage les développeurs à construire une suite ordonnée de tâches spécifiques pour chaque modification envisagée. Chaque tâche représente un bâtonnet à retirer du jeu.

En suivant cette liste de tâches, qui sera représentée sous forme de graphe comme on le verra plus loin, les développeurs retirent les bâtonnets un par un, en s'assurant que le code fonctionne correctement à chaque étape avant de passer à la suivante. Comme dans le jeu, lorsque ça ne fonctionne pas on remet le bâtonnet à sa place initiale et on recommence ! Si une tâche se révèle complexe ou entraîne des problèmes imprévus, on peut essayer de la découper ou passer à d'autres tâches qui paraissent plus simples. Cette approche séquentielle permet de gérer les risques et de minimiser les perturbations dans le code existant.

Contexte du développement logiciel et défis liés au code legacy

Le développement logiciel est un domaine en constante évolution, où de nouvelles technologies et pratiques émergent régulièrement. Cependant, de nombreuses organisations se retrouvent avec des systèmes et des applications existantes, souvent appelés "legacy", qui ont été développés il y a plusieurs années. Parfois moins, mais c'est un autre sujet... Ce code legacy présente généralement divers défis lorsqu'il s'agit d'y apporter des modifications, pour le faire évoluer ou simplement de le maintenir.

L'un des principaux est sa complexité. Au fil du temps, de nouvelles fonctionnalités ont été ajoutées, des correctifs ont été appliqués, et différentes personnes ont pu travailler sur le code. Tout cela aboutit fréquemment à un code complexe, encore plus difficile à comprendre et à maintenir. La logique peut être enchevêtrée (#SpaghettiCode), les dépendances peuvent être mal gérées et la documentation peut être incomplète ou obsolète ! Cela rend les modifications et les ajouts de nouvelles fonctionnalités encore plus risqués, car une modification malencontreuse peut avoir des répercussions imprévues sur d'autres parties du code. Et sur ce type d'application, on ne s'en aperçoit pas toujours rapidement.

La peur de perturber le fonctionnement existant est un autre enjeu majeur. Les systèmes basés sur du code legacy sont souvent critiques pour l'activité de l'entreprise, et, comme on vient de le voir, toute modification a le potentiel pour causer des problèmes ou des erreurs. Cela peut amener les développeurs à être réticents à apporter des modifications, ce qui limite l'agilité et l'innovation. De plus, la documentation et les tests automatisés peuvent être insuffisants, ce qui complique la tâche des développeurs pour comprendre l'impact potentiel de leurs modifications.

La présence de technologies obsolètes ou dépréciées apporte aussi son lot de difficultés. Le code legacy peut être basé sur des langages de programmation anciens ou des bibliothèques obsolètes qui ne sont plus largement supportés ou maintenus. Cela peut poser des problèmes de compatibilité et de sécurité, ainsi que limiter les possibilités d'intégration avec de nouvelles technologies.

Face à ces défis, la réécriture du code devient souvent une nécessité pour améliorer la maintenabilité, la flexibilité et la performance du système. Cependant, une réécriture complète peut être coûteuse, risquée et chronophage. Mais grâce à la méthode Mikado, grâce à son approche progressive et itérative vous pourrez aborder la réécriture du code legacy de manière plus contrôlée et sécurisée.

Comprendre la méthode

Analogie avec le jeu du Mikado

L'analogie avec le jeu du Mikado est au cœur de la méthode Mikado et fournit une perspective intéressante sur la manière dont elle s'applique au développement logiciel. Le jeu du Mikado consiste à retirer des bâtonnets d'un tas sans faire bouger les autres bâtonnets. Cette analogie offre une vision visuelle et intuitive du processus de refactoring du code legacy.

Dans le jeu du Mikado, chaque bâtonnet est connecté aux autres de différentes manières. Si vous retirez un bâtonnet sans prêter attention aux autres, vous risquez de faire bouger les bâtonnets adjacents, ce qui peut entraîner un déséquilibre et la chute du tas. Perdu ! Pour réussir dans le jeu, vous devez choisir judicieusement le bâtonnet à retirer en tenant compte de ses connexions avec les autres bâtonnets.

Dans le développement logiciel, chaque partie du code legacy peut être considérée comme un bâtonnet dans le jeu du Mikado. Chaque section du code est interconnectée avec d'autres parties, qu'il s'agisse de dépendances entre modules, de flux de données ou d'appels de fonctions. Lorsque vous modifiez une partie du code, vous devez prendre en compte ces dépendances et vous assurer que les modifications n'affectent pas négativement les autres parties du système.

La méthode Mikado applique cette analogie en encourageant les développeurs à identifier les dépendances entre les différentes parties du code legacy et à planifier soigneusement les modifications à apporter. Avant de retirer un bâtonnet (effectuer une modification), il est important de comprendre comment cela affectera les autres parties du système (les autres bâtonnets). Cela implique de réfléchir aux conséquences potentielles, d'anticiper les effets de bord et de mettre en place des mesures d'atténuation si nécessaire.

En planifiant de manière séquentielle et itérative, les développeurs peuvent retirer les bâtonnets un par un, en s'assurant que chaque modification fonctionne correctement avant de passer à la suivante. Cela permet d'éviter les perturbations majeures dans le code existant et de minimiser les risques d'erreurs ou d'effets indésirables.

Cette approche progressive permet de gérer les défis imprévus de manière contrôlée et de maintenir une trajectoire claire vers l'objectif final de réécriture du code legacy.

Principes de base

La méthode Mikado repose sur plusieurs principes de base qui guident son application efficace lors de la réécriture du code legacy.

Ces principes visent à faciliter la gestion des dépendances, à minimiser les risques et à permettre une progression itérative dans le processus de réécriture.

Voici les principes clés de la méthode Mikado.

Définir un objectif clair

Avant de commencer la réécriture du code, il est essentiel de définir clairement l'objectif final à atteindre. Cela peut être l'ajout d'une nouvelle fonctionnalité, la correction d'un bug ou l'amélioration des performances. Avoir un objectif clair permet de maintenir le cap tout au long du processus.

Implémenter l'objectif naïvement

Écrire une solution simple, naïve, de l'objectif à atteindre et vérifier si elle fonctionne. Cette approche vous fera souvent gagner du temps en évitant les analyses inutiles. Mais parfois, il vous faudra réfléchir un peu plus et analyser succinctement le problème. Dès que l'analyse dure plus de quelques minutes, expérimentez une solution !

Trouver les erreurs

S'il y a des erreurs de compilation, d'exécution des tests ou même des problématiques pour implémenter une solution, c'est qu'il y a des prérequis à ajouter pour réaliser la tâche. Si, au contraire, tout est conforme alors la tâche est résolue et on peut remonter à la tâche parente.

Corriger les erreurs

Les solutions ne se limitent pas au code. Il est possible d'intervenir sur le build, l'infrastructure, les ressources, etc. Il ne faut pas se lancer dans des analyses trop poussées ou dans la prédiction d'éventuels problèmes qui pourraient être provoqués par une solution. Les erreurs potentielles remonteront d'elles-mêmes en appliquant la méthode. Lorsqu'une solution est trouvée, il est alors possible d'ajouter des tâches pour la rendre un peu plus propre. Par exemple, on peut tester avec une valeur en dur puis, si ça fonctionne, chercher à passer une valeur dynamique. La solution doit avoir du sens !

Revenir en arrière

Lorsque la solution n'atteint pas l'objectif visé, contentez-vous d'ajouter les problèmes rencontrés comme nouveaux prérequis et faites un retour à l'état précédent de votre code. Même si vous êtes revenu à l'état initial de votre code, vous avez acquis de la connaissance. Aussi, n'ayez pas peur de perdre cette solution ; qui vous garantie qu'elle sera toujours valide par la suite ?

Valider et itérer

Pour chaque tâche, répétez le même processus et descendez dans le graphe, jusqu'à résoudre une tâche. Vous pouvez considérer que la tâche est résolue lorsque :

• le code compile,
• les tests passent,
• l'application semble fonctionner,
• la correction a du sens.

Si c'est le cas, vous pouvez commiter cette solution et revenir à sa tâche parente. Continuez, jusqu'à réaliser toutes les actions et ainsi atteindre l'objectif initial. On retrouve là le concept du TCR, proposé par Kent Beck.

En suivant ces principes, la méthode Mikado vous permettra d'aborder la réécriture du code legacy de manière progressive, contrôlée et sécurisée.

Avantages et bénéfices

La méthode Mikado offre plusieurs avantages. En voici quelques-uns :

1. Gestion des risques :

La méthode Mikado permet d'aborder la réécriture du code legacy de manière itérative et incrémentale. Cela facilite la gestion des risques en identifiant les tâches et les dépendances de manière progressive. En cas de problème ou de difficulté, il est plus facile de maîtriser l'impact potentiel et de prendre des mesures correctives spécifiques. La prise en compte proactive des risques potentiels à chaque étape contribue à minimiser les impacts négatifs et à anticiper les problèmes.

2. Minimisation des impacts :

  La méthode Mikado vise à minimiser les impacts sur le système pendant la réécriture du code legacy. En abordant les tâches de manière séquentielle, il est possible de limiter les modifications simultanées et les répercussions sur les fonctionnalités existantes. Cela réduit les risques de régressions et permet de maintenir le fonctionnement du système tout au long du processus de réécriture. Il est important de préserver la stabilité et la fiabilité du système pendant la transition !

3. Suivi du progrès :

  La méthode Mikado favorise un suivi clair et précis du progrès de la réécriture du code legacy. En ajoutant des tâches et en les retirant au fur et à mesure de leur réalisation, il est facile d'avoir une vision du progrès accompli. Cela aide à garder une trace des tâches effectuées, des tâches en cours et des tâches restantes. Le suivi du progrès permet de mesurer l'avancement global du projet, d'évaluer les délais et de réajuster si nécessaire. Il fournit également une motivation en montrant les résultats concrets obtenus à chaque étape.

4. Flexibilité et adaptation :

  la méthode Mikado offre une certaine flexibilité et la possibilité de s'adapter aux circonstances changeantes. En identifiant les tâches de manière séquentielle, il est possible d'ajuster l'ordre des tâches en fonction des nouvelles informations, des besoins émergents ou des contraintes externes. Cela permet de prendre en compte les changements imprévus et de réagir de manière appropriée. La méthode Mikado facilite l'adaptation tout en maintenant une structure et une organisation claires.

5. Communication et collaboration :

  La méthode Mikado encourage la communication et la collaboration entre les membres de l'équipe. En partageant une vision claire des tâches à réaliser, des dépendances et des progrès accomplis, les membres de l'équipe peuvent travailler de manière plus coordonnée et efficace. La méthode Mikado facilite la compréhension mutuelle, la résolution des problèmes et la prise de décisions basées sur des informations concrètes.

Limites et considérations

Limites potentielles

Complexité des dépendances

La méthode Mikado suppose que les dépendances entre les différentes parties du code sont bien connues et peuvent être identifiées de manière précise. Cependant, dans certains systèmes complexes, il peut être difficile de déterminer toutes les dépendances de manière exhaustive. Cela peut rendre l'ajout de tâches et la planification des étapes plus complexes, ce qui peut augmenter le risque d'omissions ou de problèmes non anticipés.

Difficulté à estimer la durée des tâches

L'estimation de la durée nécessaire pour traiter une tâche peut être un défi. D'autant plus que vous passez d'un mode exploratoire à un mode correction ! Les problèmes imprévus, les dépendances cachées ou les difficultés techniques peuvent prolonger la durée d'une tâche, ce qui peut avoir un impact sur la planification globale du projet. Il est important de garder une certaine flexibilité et d'ajuster les estimations au fur et à mesure que de nouvelles informations ou des défis surgissent.

Risque de négliger la conception globale

En se concentrant sur des actions spécifiques et séquentielles, il existe un risque de négliger la vision d'ensemble et la conception globale du système. La méthode Mikado met l'accent sur des modifications itératives, mais il est essentiel de prendre du recul de temps en temps pour évaluer l'architecture globale, l'interopérabilité des modules et les performances à long terme.

Nécessité d'une documentation et d'une communication claires

Pour assurer une transition fluide et efficace, une documentation claire et une communication transparente sont essentielles. Il est important de tenir à jour l'arbre de tâches, de documenter les dépendances, les décisions de conception et les problèmes rencontrés. La communication entre les membres de l'équipe de développement, les parties prenantes et les utilisateurs est cruciale pour éviter les malentendus et les erreurs de coordination.

Il est important de prendre en compte ces limites potentielles lors de l'application de la méthode Mikado. Bien qu'elle offre de nombreux avantages, il est essentiel de rester conscient des défis possibles et d'adapter l'approche en conséquence pour garantir le succès de la réécriture du code legacy.

Considérations à prendre en compte avant de se lancer

Sauvegardes et mesures de sécurité

Avant de commencer la réécriture, il est recommandé de réaliser des sauvegardes complètes de la codebase et de mettre en place des mesures de sécurité appropriées. Cela garantit qu'en cas de problèmes majeurs ou de régressions, il est possible de revenir à l'état précédent du système sans perte de données ou d'interruptions majeures. La mise en place d'un système de contrôle de versions, par exemple Git, est vivement recommandé. Mais qui peut encore s'en passer ?

Validation et tests approfondis

À chaque étape de la réécriture, il est essentiel de réaliser des tests approfondis pour valider les modifications et garantir leur bon fonctionnement. Cela inclut des tests unitaires, des tests d'intégration et des tests de non-régression pour s'assurer que les fonctionnalités existantes ne sont pas affectées. Les tests rigoureux permettent d'identifier les problèmes potentiels plus tôt dans le processus et de les corriger rapidement. Lorsque des tests manquent, vous pouvez les ajouter avant de modifier le code ou vous tourner vers les tests d'approbation.

Pour en savoir plus sur ces tests, je vous invite à lire l'article sur notre blog.

Communication efficace

Une communication efficace est essentielle tout au long de la réécriture du code legacy. Il est important que toute l'équipe, technique et non technique, comprennent les bénéfices qui seront apportés par la réécriture du code. Pensez à communiquer régulièrement avec les parties prenantes. La communication transparente permet de gérer les attentes et de minimiser les perturbations. Le graphe est un des outils à votre disposition pour communiquer.

Engagement et ressources adéquats

La réécriture du code legacy est un processus complexe et intense. Il est important de s'assurer que l'équipe de développement dispose des ressources adéquates en termes de compétences, de temps et de soutien. L'engagement de l'équipe et la disponibilité des ressources nécessaires sont essentiels pour garantir le succès du processus de réécriture. Cependant, rien n'oblige à traiter un problème en une seule fois. La réalisation d'objectifs secondaires est déjà une avancée vers un code plus propre.

Conclusion

La réécriture du code legacy peut être une tâche complexe et intimidante mais nous avons vu dans cet article que la méthode Mikado offre une approche efficace pour gérer ce processus. Avec cette méthode, vous pouvez bénéficier des avantages suivants :

* Gestion des risques

* Minimisation des impacts

* Suivi du progrès

* Flexibilité et adaptabilité

* Approche itérative et progressive

Cette méthode offre une approche structurée et réfléchie pour la réécriture du code legacy. Elle vous permet de gérer les risques, de minimiser les impacts, de suivre le progrès et d'adopter une approche itérative. En l'utilisant, vous pouvez aborder la réécriture du code legacy de manière plus efficace, en améliorant la qualité du code et en garantissant une transition fluide vers un système amélioré.

Pour aller plus loin :

* [Le livre](http://www.manning.com/TheMikadoMethod)

* [Site web](https://mikadomethod.info/)

* [Kata](https://github.com/mikadomethod/space)

‍