La refactorisation est un exercice qui devrait être maîtrisé par tous les développeurs, encadré par tous les chefs de projets et encouragé par tous les directeurs techniques.
Le refactoring, qu’est-ce que c’est ?
Derrière cet affreux anglicisme se cache le fait de réécrire du code qui a déjà été développé. Le but n’est donc pas d’ajouter de nouvelles fonctionnalités, mais plutôt d’assurer un suivi de l’existant, de faire un ménage qui en facilitera la maintenance.
Nous nous sommes tous retrouvés un jour ou l’autre devant des bouts de code sans queue ni tête, manifestement écrits à la va-vite, ne respectant aucune norme, avec une documentation périmée, sans commentaire, ou truffés de code mort. À chaque fois, nous sommes horrifiés. Dans le meilleur des cas, on se souvient des raisons historiques qui ont conduit à cela (« Ah oui, ça date du projet X, qu’on avait dû faire à toute vitesse il y a 2 ans ») ; dans le pire des cas, on va retrouver le responsable de cette horreur pour lui passer un savon.
Mais la bonne attitude, c’est d’organiser l’amélioration de ce code. Il faut garder en tête qu’on ne travaille pas continuellement sur les mêmes fichiers. Ce qu’on est en train de développer un jour sera utilisé pendant des mois voire des années sans qu’on revienne dessus. Mais au fil du temps, le code ancien devient « friable » : chaque correction de bug devient plus délicate et sujette aux bugs de régression ; chaque ajout de fonctionnalité prend de plus en plus de temps et devient plus difficile.
Je vais faire un parallèle avec la construction immobilière. Quand on construit une maison, on commence par faire les fondations, puis on monte les murs extérieurs, puis le toit et enfin les cloisons intérieures. Quand on développe un logiciel, c’est un peu la même chose ; chaque développement, chaque ajout de fonctionnalité, s’appuie sur des objets ou des librairies qui doivent rester fiables dans le temps. Il faut donc pouvoir revenir à tout moment sur n’importe quel bout de code, accéder à sa documentation, lui ajouter de nouvelles capacités, voire résoudre des bugs qui ne s’étaient encore jamais déclarés.
Parce que le jour où vous faites tomber des cloisons, vous ne devez pas devoir refaire les murs extérieurs ; et si vous ajoutez une étage à votre maison, vous devez pouvoir faire confiance à la chape de béton de vos fondations.
Comment s’y prendre
On peut découper un refactoring en 4 étapes précises. Les trois premières sont importantes et nécessaires, alors que la dernière est à mettre en oeuvre si le besoin s’en fait sentir uniquement.
