J'ai lu ça et là pas mal de choses sur la Mikado Method ces derniers temps. J'ai pu profiter de longues heures de vol pour dévorer le bouquin (je vous ai dit que je possédais un Kindle ?)
Il s'agit d'une méthode pour faire du refactoring dans du code legacy. On peut la voir comme une amélioration ou une industrialisation au draft refactoring proposé par Michael Feathers dans Working Effectively With Legacy Code (pas de lien, j'ai déjà fait une pub gratos pour Amazon plus haut).
Vous avez tous joué aux mikados. On a plein de bâtonnets en foutoir et il faut les récupérer un par un sans faire bouger les autres. L'objectif est de récupérer celui avec la spirale bleue appelé... le mikado ! Celui-ci fait gagner plein de points et assure au joueur qui s'en empare de remporter la victoire. Si on fait bouger un autre bâtonnet, on passe son tour et on est frustrer d'avoir à attendre pour recommencer.
Si on reprend cette analogie, le refactoring proposé par la mikado method s'apparente à jouer au mikado comme un gros bourrin : en essayant de choper le mikado dès le début du jeu ! On ne sait jamais, si cela fonctionne, on aura gagné un paquet de temps et d'énergie...
Voilà comment ce déroule le processus :
- Vous vous fixez votre objectif. Cela peut être d'ajouter une fonctionnalité, ou de diminuer le couplage entre plusieurs composants, etc. Il s'agit de l'objectif final. Il vous semble difficile à remplir directement. Sinon, ce n'est pas drôle.
- Vous essayez d'attendre l'objectif directement, réalisant les actions à mener sans vous soucier du reste du code.
- Normalement, dans tout bon système legacy (c'est à dire existant depuis plus de deux jours en moyenne...), votre projet ne doit plus compiler car vous avez des erreurs de compilation sur énormément de classes. Cette situation dégage un objectif secondaire : vous devez régler ces problèmes avant de remplir votre objectif principal. Vous le notez.
- C'est le plus important et le plus douloureux : vous faites un revert des modifications pour rendre le système à nouveau fonctionnel.
- Vous tentez d'atteindre les objectifs secondaires avant l'objectif initial. Si cela ne fonctionne pas, vous dégagez de nouveaux objectifs, faites un rollback et recommencez.
- Itérez jusqu'à la mort ou jusqu'à avoir rempli l'objectif principal (ou les deux, comme dirait mon chef).
J'ai trouvé ça plutôt intéressant et vous incite à lire le livre. Un point fort je trouve est que les auteurs proposent d'accompagner les différentes étapes par la mise en place d'un diagramme montrant les différents objectifs à remplir et les liens entre eux. Ceci permet de faciliter la communication dans l'équipe et de voir l'avancement dans la réalisation de l'objectif initial.
Je suis arrivé sur un nouveau projet legacy (il a plus de 2 jours), et j'imagine déjà des cas dans lesquels je pourrai utiliser cette Mikado Method !
