Refactorisation

La refactorisation consiste à améliorer la structure interne du code sans changer son comportement externe.

Cette définition comporte deux parties essentielles :

Améliorer la structure : Rendre le code plus facile à comprendre, modifier ou étendre. Cela inclut de meilleurs noms, des fonctions plus petites, une organisation plus claire, moins de duplication.

Sans changer le comportement : Le code fait exactement ce qu'il faisait avant. Les entrées produisent les mêmes sorties. Les effets secondaires sont identiques. Les tests passent toujours.

La refactorisation n'est pas :

• Réécrire à partir de zéro
• Ajouter des fonctionnalités
• Corriger des bogues
• Optimiser les performances (habituellement)

Si vous changez ce que fait le code, vous ne faites pas de refactorisation — vous faites autre chose. La refactorisation concerne spécifiquement la structure, pas le comportement.

Martin Fowler a documenté des dizaines de refactorisations spécifiques, chacune avec :

• Un nom (pour que les équipes puissent communiquer)
• Une motivation (quand l'utiliser)
• Une mécanique (comment le faire de manière sécuritaire, étape par étape)

Voici quelques-unes que vous utiliserez constamment :

Extraire une fonction : Prendre du code et le mettre dans une nouvelle fonction avec un nom clair. C'est probablement la refactorisation la plus courante.

Renommer : Changer le nom d'une variable, fonction ou classe pour mieux exprimer son objectif. Les bons noms sont étonnamment importants.

Intégrer une fonction : L'opposé d'extraire — remplacer un appel de fonction par son corps. À utiliser quand une fonction n'ajoute pas de clarté.

Extraire une variable : Prendre une expression complexe et lui donner un nom en l'assignant à une variable.

Déplacer une fonction : Déplacer une fonction vers une classe où elle a plus de sens.

Remplacer une condition par du polymorphisme : Remplacer des instructions if/else ou switch complexes par une répartition orientée objet.

Ce ne sont pas des refactorisations « avancées ». Ce sont des outils quotidiens. Apprenez-les jusqu'à ce qu'ils deviennent automatiques.

La refactorisation n'est sécuritaire que lorsque vous avez des tests. Sans tests, chaque changement pourrait briser quelque chose, et vous ne le saurez qu'en production.

Le processus sécuritaire :

1. S'assurer que les tests passent avant de commencer
2. Faire un petit changement
3. Exécuter les tests
4. Si les tests passent, continuer ; s'ils échouent, annuler immédiatement
5. Répéter

Les petites étapes sont essentielles. N'essayez pas de refactoriser cinq choses à la fois. Extrayez une fonction, exécutez les tests, validez. Renommez une variable, exécutez les tests, validez. De cette façon, si quelque chose se brise, vous savez exactement ce qui l'a causé.

Les IDE modernes ont des refactorisations automatisées qui sont plus sécuritaires que les changements manuels. « Renommer » dans votre IDE met à jour toutes les références. « Extraire une fonction » crée la fonction et met à jour le site d'appel. Utilisez ces outils.

La règle du scout : Laissez le code en meilleur état que vous l'avez trouvé. Quand vous touchez du code pour n'importe quelle raison, faites une petite amélioration. Avec le temps, la base de code devient plus propre au lieu de plus sale.

Refactorisez constamment. La refactorisation n'est pas une phase ou un sprint séparé. C'est continu.

Déclencheurs spécifiques pour refactoriser :

Avant d'ajouter une fonctionnalité : Si la structure actuelle rend la fonctionnalité difficile à ajouter, refactorisez d'abord. Rendez le changement facile, puis faites le changement facile.

Après avoir fait passer un test : C'est le « refactoriser » dans rouge-vert-refactoriser. Nettoyez avant de passer au test suivant.

Quand vous remarquez une odeur de code : Code dupliqué, méthodes longues, noms peu clairs, conditions complexes — ce sont des signaux qu'une refactorisation est nécessaire.

Pendant la revue de code : Si vous voyez quelque chose que vous amélioreriez, faites-le ou notez-le pour plus tard.

Quand vous avez du temps : Ayez un « backlog de refactorisation » de problèmes connus. Quand vous avez du mou, choisissez quelque chose de la liste.

Ne refactorisez pas quand :

• Vous n'avez pas de tests
• Vous êtes sur le point de livrer (stabilisez, ne changez pas)
• Vous ne comprenez pas ce que fait le code (comprenez d'abord)

La dette technique est le coût accumulé de prendre des raccourcis. Chaque fois que vous dites « Je vais nettoyer ça plus tard » et que vous ne le faites pas, vous ajoutez de la dette. Chaque fois que vous copiez-collez au lieu d'extraire, vous ajoutez de la dette.

La dette accumule des intérêts. Le code désordonné prend plus de temps à changer. Les bogues se cachent dans la complexité. Les nouveaux membres de l'équipe ont du mal à comprendre. Le coût du changement augmente.

La refactorisation est la façon dont vous remboursez la dette. Une refactorisation régulière maintient la dette gérable. Négliger la refactorisation laisse la dette s'accumuler jusqu'à ce que la base de code devienne impraticable.

L'idée clé : La refactorisation n'est pas un luxe. C'est un entretien essentiel. Vous ne demandez pas la permission de rembourser la dette — vous le faites simplement dans le cadre de votre travail.

XP intègre la refactorisation dans le processus. Chaque fonctionnalité, chaque correction de bogue, chaque tâche inclut du temps pour laisser le code en meilleur état que vous l'avez trouvé. Vous n'avez pas besoin d'un « sprint de refactorisation » — vous avez besoin d'une habitude de refactorisation.