Martin Fowler, auteur du livre « Refactoring : Improving the Design of Existing Code », a récemment publié un article sur son site web explorant les différents workflows pour intégrer de manière efficace le refactoring dans le travail quotidien du développeur.
Il explique aussi comment utiliser les différents types de workflow et suggère que « pour utiliser le refactoring de la meilleure manière, il faut combiner tous les types de workflow de refactoring de manière explicite pour le développeur ».
Fowler définit le refactoring comme « … une technique disciplinée pour restructurer une partie de code existante, en altérant sa structure interne sans changer son comportement externe ».
Joshua Kerievsky suggère dans son livre « Refactoring to Patterns » :
En améliorant, continuellement le design de son code, il est de plus en plus facile de travailler avec. C’est un vif contraste avec ce qui se produit habituellement : très peu de refactoring et une grande attention à ajouter expéditivement des nouvelles fonctionnalités. En s’habituant à refactorer de manière continue, il est plus facile d’étendre et de maintenir son code.
Bien que Fowler déclare que le refactoring est devenu aujourd’hui une technique bien connue, il pense que de nombreuses équipes de développeurs gagneraient à mieux comprendre les différents types de workflow du refactoring qui peuvent être utilisés. Ainsi, ils pourraient utiliser le meilleur workflow en fonction de la situation rencontrée.
Le site web SourceMaking décrit les situations dans lesquelles on doit refactorer. Elles sont basées sur la « règle des trois » attribuée à Don Roberts.
« La première fois que tu fais quelque chose, tu le fais. La seconde fois que tu fais quelque chose de similaire, tu grimaces à dupliquer, mais tu le dupliques quand même. La troisième fois que tu fais quelque chose de similaire tu refactore ».
- Quand tu ajoutes une fonction
- Quand tu répares un bug
- Quand tu fais une revue de code
Fowler introduit la métaphore des « deux chapeaux » (Two Hats) pour expliquer ou pour mémoire, que durant les diverses tâches, soit le développeur ajoute de nouvelles fonctionnalités (chapeau d’ajout de fonctionnalités), soit il améliore la qualité du code (le chapeau de refactoring). Il ajoute que lorsque l’on développe on peut changer fréquemment de chapeaux, parfois toutes les minutes. Mas... on ne peut en porter qu’un et un seul à la fois.
Avec cette métaphore, Fowler décrit le premier workflow, probablement le plus utilisé, le « TDD Refactoring ». Il est construit selon le cycle suivant : depuis un état stable, écrire un test qui échoue. Ensuite, le faire réussir puis finalement améliorer la qualité du code. Urs Enzler de planetggek.ch détaille la relation entre test-driven developpement et le refactoring.
"Litter-Pickup Refactoring" est le workflow suivant. Fowler propose son utilisation quand toute une partie du code est mal écrite. Le principe qui se cache derrière est : « En nettoyant le code, comme on est à l’intérieur, on le rend plus facile à modifier lorsque l’on devra le faire. Peut-être même encore plus rapidement si on le modifie maintenant ».
Fowler explique les détails de "Comprehension Refactoring". Cela rend le code plus facile à comprendre et donc facile à utiliser et à maintenir. Une référence au Ward Cunningham texte a été utilisée pour compléter cette idée :
« Dès que l’on a besoin de réfléchir à ce que fait le code, nous construisons tous un certain cheminement de compréhension. Dès qu’il est abouti, nous devrions laisser une trace de notre compréhension dans le code. Ainsi, personne n’aura à recommencer cet effort depuis le début ».
Il décrit aussi trois autres workflows, qu’il dit aussi important que les trois premiers :
- Le "Preparatory Refactoring" à appliquer quand on commence une nouvelle tâche ;
- Le "Planned Refactoring" à appliquer lorsque des grandes parties du code sont problématiques et nécessitent une attention particulière ;
- Le "Long-Term Refactoring" à appliquer lorsque l’on doit remplacer un module important durant plusieurs itérations.
Avez-vous déjà refactoré?