Chaque modification de code sans refactorisation aggrave et propage les problèmes de qualité. Ce code dégradé est source de frustration et de perte de temps, et réduit considérablement la durée de vie des systèmes opérationnels. Dans un contexte agile, il peut faire la différence entre le respect et le non-respect des délais d'une itération.
La refactorisation impitoyable du code empêche sa dégradation, garantissant ainsi un code facile à maintenir et à étendre. Cette extensibilité est la raison d'être de la refactorisation et la mesure de son succès. Mais notez qu'il ne s'agit que de «safe« Remanier le code de manière aussi exhaustive est problématique si nous disposons de suites de tests unitaires complètes, comme celles obtenues avec une approche de développement pilotée par les tests (TDD). Sans la possibilité d'exécuter ces tests après chaque étape de refactorisation, nous risquons d'introduire des bogues. En revanche, dans le cadre d'un véritable développement piloté par les tests (TDD), où la conception évolue continuellement, la refactorisation régulière est incontournable, car c'est ainsi que la conception évolue. »
Hygiène du code
Une métaphore courante pour illustrer le réaménagement des tâches ménagères est celle du nettoyage de la cuisine pendant la préparation des repas. Dans toute cuisine où plusieurs repas complexes sont préparés chaque jour pour un certain nombre de personnes, le nettoyage et le réaménagement sont généralement des opérations continues. Quelqu'un est responsable de la propreté et de l'organisation constantes de la vaisselle, des casseroles, de la cuisine elle-même, des aliments et du réfrigérateur. Sans cela, la préparation continue des repas deviendrait rapidement impossible. Chez vous, vous pouvez constater les conséquences non négligeables du simple fait de reporter le nettoyage de la vaisselle, même pour de petites quantités : avez-vous déjà essayé de gratter la saleté incrustée de biscuits apéritifs au chocolat séchés dans un bol ? Deux secondes de rinçage manquées peuvent se transformer en dix minutes de nettoyage intensif.
« refactorisations » spécifiques
Les refactorisations sont l'antithèse du bricolage interminable du code ; elles sont précises et limitées dans le temps. L'ouvrage de référence de Martin Fowler livre Cet ouvrage décrit 72 techniques de refactorisation spécifiques (par exemple, « extraire une méthode », qui extrait un bloc de code d'une méthode et crée une nouvelle méthode à partir de ce bloc). Chaque refactorisation transforme une section de code (un bloc, une méthode, une classe) de l'un des 22 états « à éviter » bien connus vers un état plus optimal. Apprendre à identifier les opportunités de refactorisation et à les mettre en œuvre correctement demande du temps.
Refactorisation vers des modèles
La refactorisation ne se limite pas aux niveaux bas du code. Dans son récent ouvrage, Refactorisation vers des modèlesDans son ouvrage, Joshua Kerievsky démontre avec brio que le refactoring est la technique idéale pour intégrer les patrons de conception du « Gang of Four » à notre code. Il soutient que ces patrons sont souvent surutilisés et introduits trop tôt dans les systèmes. Il reprend le format original de Fowler, qui consiste à présenter et nommer des « refactorings » spécifiques, véritables recettes pour faire passer son code du point A au point B. Les refactorings de Kerievsky sont généralement de plus haut niveau que ceux de Fowler et s'appuient souvent sur ces derniers. Kerievsky introduit également le concept de refactoring « vers » un patron, expliquant comment de nombreux patrons de conception possèdent plusieurs implémentations, ou niveaux de profondeur d'implémentation. Parfois, on a besoin de plus d'un patron que d'autres fois, et ce livre montre précisément comment progresser, partiellement ou totalement, vers l'objectif.
Le flux de refactorisation
Dans une approche de développement axée sur les tests (TDD), la refactorisation suit le même déroulement que toute autre modification de code. Vous disposez de vos tests automatisés. Vous commencez la refactorisation en apportant la plus petite modification discrète possible qui compile, s'exécute et fonctionne. Dans la mesure du possible, vous effectuez ces modifications en ajoutant du code au code existant, en parallèle. Vous exécutez les tests. Vous apportez ensuite la prochaine petite modification discrète et exécutez à nouveau les tests. Une fois la refactorisation en place et tous les tests exécutés avec succès, vous supprimez l'ancien code parallèle problématique. Une fois que les tests s'exécutent à nouveau avec succès, la refactorisation est terminée.
Automatisation de la refactorisation dans les IDE
La refactorisation est beaucoup plus facile à automatiser qu'à réaliser manuellement. Heureusement, de plus en plus d'environnements de développement intégrés (IDE) intègrent la prise en charge de la refactorisation automatisée. Par exemple, un IDE populaire pour Java est : éclipse, ce qui inclut de plus en plus de refactorisations automatiques. Une autre fonctionnalité appréciée est IntelliJ IDEA, ce qui a historiquement inclus encore plus de refactorisations. Dans l'univers .NET, il existe au moins deux plugins d'outils de refactorisation pour Visual Studio 2003, et il semblerait que les versions futures de Visual Studio intègrent une prise en charge de la refactorisation.
Pour refactoriser du code dans Eclipse ou IntelliJ IDEA, sélectionnez le code à refactoriser, puis déroulez le menu déroulant correspondant à la refactorisation souhaitée. L'IDE se charge du reste. Des boîtes de dialogue vous invitent à saisir les nouveaux noms des éléments à renommer, ainsi que d'autres informations. Vous pouvez ensuite relancer immédiatement vos tests pour vérifier que la modification n'a rien cassé. En cas de problème, vous pouvez facilement annuler la refactorisation et analyser le problème.
