Ces derniers temps, j’ai eu plusieurs discussions avec d’autres informaticiens, orientées sur des sujets comme les méthodes agiles en général et plus particulièrement les tests unitaires. C’est toujours intéressant de confronter sa propre vision à celle des autres. Une des choses qui m’a marqué, c’est que plus de la moitié…
La refactorisation
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.
Le triangle Qualité, Coût, Délai
Quand on doit choisir la manière d’aborder un projet, il existe 3 notions fondamentales qu’il faut connaître et évaluer : la qualité, le coût et le délai.
Comprendre le triangle
- Qualité : Il s’agit du soin qui est apporté à la réalisation fonctionnelle et technique du projet. Un projet de médiocre qualité remplira les besoins immédiats du client, en s’autorisant un certain nombre de raccourcis. Un projet de bonne qualité aura été spécifié pour couvrir certains besoins futurs identifiables, et offrira une ergonomie adaptée, des performances homogènes, une évolutivité étudiée, une documentation complète.
- Coût : Un client est prêt à dépenser une certaine somme pour un projet donné. La valeur du projet peut éventuellement s’adapter à un certain nombre de critères, mais il y a forcément un seuil au-delà duquel il est impossible de le rentabiliser. La notion de coût englobe aussi bien les frais d’étude (en fonction du temps passé aux spécifications fonctionnelles et techniques) et de réalisation (suivant le nombre de développeurs nécessaires, le matériel mis à leur disposition, la présence d’une équipe de test et de validation, …), que les frais d’exploitation (matériel nécessaire pour faire tourner le projet en production, salaire de l’opérateur de maintenance, …).
- Délai : Savoir combien de temps doit durer la réalisation d’un projet n’est pas aisé, même si cela fait partie du travail d’un ingénieur. Certains projets ne sont pas urgents, ni même importants, mais ils comportent forcément une deadline à partir de laquelle ils deviennent caducs.