Refactoring : pallier l'effet tunnel grâce à la méthode Mikado
« Méthode ! Méthode ! », hurlait ma prof de maths de Maths Sup. Ça faisait mal aux oreilles, mais elle avait raison. Elle avait raison de parler de méthode, car s’il est un domaine où il en faut, de la méthode, c’est bien le refactoring.
Mise en situation
Il fait beau, il fait frais ce matin, vous avez bien dormi et vous vous sentez d’attaque pour refactorer : noble intention.
Le problème, c’est que très vite, un changement en appelle un deuxième, puis un troisième, et la liste s’allonge sans cesse. Vous ouvrez des parenthèses sans jamais les refermer. Au bout d’une heure, l’appli ne se lance plus, au bout de deux, la compilation n’est plus qu’un vague souvenir, et à midi trente, il est l’heure de déjeuner.
Un café ☕️ et c’est reparti : bon, ça serait quand-même bête de perdre une matinée de travail, non ? Donc on continue, on continue de tirer le fil de la pelote et on ouvre de nouvelles parenthèses. Vous êtes en plein biais d’engagement.
Pour rappel, l’application ne compile plus, donc vos changements sont de plus en plus cassants. Vous travaillez sans filet et introduisez des bugs à tour de bras.
Votre codebase a maintenant un faux-air de scène post-apocalyptique ☠️ Une semaine a passé, vous sentez le souffle de votre manager qui passe derrière votre dos en se pinçant les lèvres pour ne rien dire.
Il est temps d’introduire ici un peu de méthode. Observons : « Le problème, c’est que très vite, un changement en appelle un deuxième, puis un troisième, et la liste s’allonge sans cesse. »
Le problème des dépendances entre refactorings
La réponse est sous nos yeux : chaque changement à mettre en œuvre dépend d’un autre changement, jusqu’à un dernier qui, lui, ne dépend de rien. Ainsi se dessine un arbre de dépendances.
La méthode Mikado procède donc en 2 étapes :
-
La première étape, phase d’exploration ou d’acquisition de connaissances [↘️], consiste à établir cet arbre. En partant du changement que l’on souhaite effectuer, on établit le prochain changement dont il dépend, et le suivant, et le suivant jusqu’à arriver aux feuilles de l’arbre. Chose singulière, à chaque étape on repart de l’état initial (
reset --hard). Utile pour travailler sur une base propre et évaluer les conséquences précises du changement à l’étude. Toutefois, si le changement est petit, il peut être mis en œuvre directement. -
Une fois cet arbre établi, la phase de refactoring peut démarrer [↖️]. Elle procède en partant des feuilles pour remonter jusqu’à la racine de l’arbre, c’est-à-dire le changement dont tout était parti. L’analogie avec le jeu de Mikado fait sens : on n’accède à la dernière baguette qu’en ayant retiré toutes les autres au préalable.
Les enjeux du refactoring
Cette méthode contribue, comme le pattern Strangler Fig, à pallier l’effet tunnel et éviter la mega-refonte censée durer 1 an et qui sera finalement abandonnée au bout de 2.
L’autre sujet majeur du refactoring est bien sûr le risque de régressions, que l’on peut limiter grâce à la méthode du Golden Master. Tous ces sujets sont étudiés en détail et de manière pratique dans la formation L’art du refactoring.
Alors… happy coding! 💻