samedi 6 mars 2010

Réflexions sur le refactoring

Après avoir passé quelques semaines à remettre en état du code truffé de duplications et de problèmes de conception, j'en suis arrivé à quelques conclusions.

Celle qui me paraît la plus importante fait écho à un twit de Kent Beck : "if you want to eliminate duplication first make the similar code exactly identical, then eliminating duplication is trivial". J'en ai fait l'expérience : si des portions de code se ressemblent, il est aisé de les rendre les plus identiques possible et il devient effectivement trivial de faire disparaître la duplication. La première étape peut se faire à l'aide de méthodes simples de refactoring comme le renommage de variables ou de méthodes, ou en déplaçant des lignes de codes. Le risque est donc très faible.

Ensuite, un simple outil de diff (vim, par exemple :)) permet d'extraire les parties communes ou, tout simplement, de constater l'égalité de deux portions de code (voire de fichiers). À partir de là, les méthodes habituelles de refactoring s'appliquent le plus simplement du monde.

Il est inutile de vouloir reprendre l'intégralité du code en une seule fois. Il est plus facile de travailler par étapes, classe par classe, par exemple. Refactorer une classe, la valider, l'intégrer, et passer soit à la suivante, soit à une autre tâche. Il est toujours temps de revenir sur celles qui restent à faire.

Certaines améliorations impliquent des modifications en profondeur. Là encore, il est plus sûr et plus aisé de procéder par étapes. Par exemple, la factorisation de code au sein d'un ensemble de classes peut faire apparaître un nouveau niveau de factorisation ou mettre en évidence une nouvelle architecture de classes. Il est préférable d'aller au bout de la première factorisation avant de se lancer dans le second niveau. Sinon, le travail à effectuer sur le code peut devenir complexe et, finalement, difficile à maîtriser.

Voilà pour cette fois, j'espère que mon expérience pourra vous être utile.