Inutile de chercher ‘Refactor’. Je n’ai jamais écrit un tel article. Si je commence directement à l’épisode 2, c’est qu’en anglais, une suite se dit ‘sequel’. Et c’est bien ce qu’il me reste après un tel traumatisme. La mission semblait facile : maintenir une application existante en corrigeant les anomalies et en implémentant les nouveaux besoins.
Le client avait insisté sur le fait que le code avait besoin de refactoring. Les nombreux développeurs qui s’étaient succédés avant moi n’avaient pas systématiquement respecté les normes de codage. Vous avez dû entendre parler de livres blancs, guidelines ou normes. Des règles de bonnes pratiques pour bien organiser le code.
L’un des objectifs de ces règles est de s’accorder sur comment on nomme une variable, une fonction, un objet, … dans un programme informatique. Pas uniquement sur la casse, mais sur les noms employés. Lorsque la mémoire était rare, les mots étaient raccourcis. Ainsi, un ‘serveur’ était écrit ‘SRV’, ‘CLT’ pour un client, …
Il n’est pas rare que pour des programmes des années 90, les noms des objets manipulés soient ainsi raccourcis. Là, c’était les noms des tables de la base de données qui étaient résumés sur 3 caractères. À moins d’avoir une table de correspondance ou de connaître parfaitement le métier, tout renommage était risqué.
Je m’avance un peu, mais à l’origine, l’opération de refactoring consiste à modifier un code pour le rendre plus lisible et ainsi faciliter sa maintenance :
- Appliquer des règles de nommage avec des noms parlants, dans une seule langue et en appliquant une casse unique par type d’objet.
- Remplacer le code qui se répète en le plaçant dans une fonction qui sera appelée à la place.
- Supprimer le code ‘mort’ qui n’est jamais utilisé.
- Découper le code en sous-fonctions s’il est trop long.
- …
Avant de se lancer dans l’aventure, des outils d’analyse de code peuvent être utilisés pour lister les erreurs les plus fréquentes. Ils calculent une note de maintenance et listent les principaux défauts du programme audité : boucles infinis, variables mal déclarées ou inutiles, objets qui ne libèrent pas la mémoire à la fin de leur utilisation, …
L’application qu’il m’était demandé de réécrire pour le rendre plus maintenable cumulait toutes les tares de la Terre. Chameau et serpents s’échappaient à chaque ligne. Des blocs entiers de codes étaient dupliqués dans les différents fichiers. L’application était composée de milliers de petits programmes invoqués à l’envie.
Certaines variables booléennes étaient nommées à l’inverse de leur objectif. Concrètement, si une variable permet de continuer un traitement, au lieu d’être nommée ‘estValide’ et de la tester à vrai pour continuer le traitement, elle s’appellait ‘estPasValide’ et le test se basait sur sa négation.
Certaines fonctions dépassaient plusieurs milliers de lignes et enchaînaient des tests avec de nombreux sous-niveaux, loin de la préconisation de créer une sous-fonction afin de ne pas dépasser deux niveaux de tests ou de boucle. Lisibilité on vous dit.
Les précédents développeurs avaient considéré qu’il était inutile de supprimer les objets à la fin de leur utilisation puisque dans d’autres langages ce traitement est réalisé automatiquement. Cette pratique transformait certaines actions en bombe logique qui faisait s’effondrer le programme au bout d’un certain nombre d’appels.
Ce code, c’était l’horreur absolue pour tout développeur qui se respecte. Et aucun de mes collègues qui m’avait précédé n’avait pensé à améliorer l’ensemble. Tout au plus, un message ‘TODO : corriger l’erreur‘ parsemait le code en ruine. Ils faisaient le minimum pour que le code fonctionne puis disparaissait dès qu’on leur demandait des corrections.
Je me suis donc mis à la tâche, corrigeant patiemment chaque non-conformité créée par la démission de mes prédécesseurs. Chaque correction demandait de s’assurer que l’application continuait à fonctionner. La régression n’est pas permise pour une application manipulée quotidiennement par ses utilisateurs.
Malgré toutes les difficultés, j’aurais pu sauver ce code. Mais je n’avais pas vu arriver la réelle menace qui plane sur les développeurs compétents, le c…