Author: 
Eric Selvais

Dans l’imaginaire collectif, le terme « refactoring » est mal interprété.
« Refactoring ? Non, impossible, cela nous coutera trop cher pour le même programme »
« Refactoring ? Pour quoi faire, ça marche très bien comme ça. On va plutôt se concentrer sur les nouvelles fonctionnalités ».
Voici quelques exemples de réaction qu’un programmeur récoltera lorsqu’il parlera de refactoring.

Mais le refactoring : qu’est-ce que c’est ?

Les Québécois traduisent littéralement le mot « refactoring » par ré-usinage. Ce terme est tout à fait approprié.
Ré-usiner une pièce mécanique ne signifie pas la jeter et en prendre une nouvelle, mais bien l’ajuster, la régler pour qu’elle améliore les performances et/ou permette de répondre au standard actuel. Ce qui garantira à l’ensemble dont elle fait partie une meilleure compétitivité.
Le « refactoring » d’un logiciel est exactement le même procédé. L’ajustement du code va permettre une amélioration des performances et permettre de correspondre au standard actuel. Ce qui garantira au logiciel une meilleure compétitivité/qualité.
Le fait de dire qu’un « refactoring » implique une réécriture complète du code est fallacieux. Seules certaines parties de code seront réécrites, jamais l’entièreté.
Répétez après moi : « Refactoring is not rewriting »

Le refactoring : comment en est-on arrivé là ?

« Tu viens de nous expliquer que le programme sera plus performant et correspondra au standard actuel.Mais au niveau fonctionnalité, rien ne change. Donc, si ça marchait avant, pourquoi le changer ? »
Effectivement, difficile de contrer cet argument. Si ce n’est en parlant du futur. Dans la majorité des cas, lorsqu’un logiciel est développé, celui-ci évoluera. Au fil du temps, beaucoup d’événements positifs peuvent arriver dans la vie du logiciel :

  • Résolution de bugs
  • Ajout de fonctionnalités
  • Arrivée d’un programmeur sur le projet (cela aura toujours un impact sur le code)
  • Nombre d’utilisateurs croissants
  • Changement d’environnement d’exécution
  • Évolution du langage de programmation

D’autres événements négatifs surviendront aussi :

  • Résolution urgente de bugs
  • Documentation non mise à jour
  • Ajout urgent de fonctionnalités
  • Le remplacement en urgence d’un programmeur

Tous ces événements provoquent une complexification du programme.
(En règle générale, dès que le mot « Urgent » apparait dans un développement, ce n’est pas bon signe.)
Il n’est pas rare, dans un programme, de retrouver des fonctionnalités entièrement copiées-collées dans différents endroits car l’urgence de la situation semblait l’exiger lors de la résolution d’un bug.
La phrase « ok, on peut le solutionner rapidement, mais il faudra prévoir du temps pour améliorer cette partie de code » signifie bien souvent « ok, on peut le solutionner rapidement mais l’idéal, serait de prévoir du temps pour améliorer cette partie de code...Tant que nous ne l'aurons pas ».


Retenons que la procrastination informatique sera, à termes, toujours coûteuse.

Le refactoring : avantages

Un code sera plus facile à maintenir (résolution de bug, ajout de fonctionnalité, migration vers une nouvelle plate-forme, ...) si le temps nécessaire à son évolution a correctement été pris.

Imaginez que vos parents vous donnent un dictionnaire qu’ils ont eux-mêmes reçu de leur parents. Ceux-ci, en vous le donnant, vous diraient : «  Il semblerait que les mots soient triés en fonction de la lettre correspondant à la page sur laquelle ils se trouvent
Par exemple :

  • 1ere page : mots triés sur la 1ere lettre
  • 2eme page : mots triés sur la 2eme lettre si elle existe sinon sur la dernière
  • ...
  • 10eme page : mots triés sur la 10eme lettre si elle existe sinon sur la dernière
  • ...  »

Etape 1 : Comment feriez-vous pour y chercher le mot « refactoring » ? Vous commenceriez par chercher un moyen logique de le trouver et finiriez par lire toutes les pages une à une.
Etape 2 : Comment feriez-vous pour y ajouter votre nom de famille ? Fort de votre expérience de recherche du mot « refactoring », vous commenceriez par relire les pages et chercheriez les mots se rapprochant le plus de votre nom pour l’ajouter avant ou après ceux-ci ou vous ajouteriez une nouvelle page.
N’importe quelle personne sensée vous le dira : il faut réorganiser ce dictionnaire. Pas le réécrire, le réorganiser.
La réorganisation permettra la modification de définition de mots et l’ajout de nouveaux mots, de manière beaucoup plus facile et prendra beaucoup moins de temps.
L’analogie avec le monde informatique est évidente :

  • Le dictionnaire représente votre logiciel
  • Vos parents représentent la vie de votre logiciel
  • Le descriptif de tri représente la documentation reçue
  • L’étape 1 : la résolution d’un bug
  • L’étape 2 : l’ajout d’une nouvelle fonctionnalité

Et enfin, la réorganisation est le « refactoring ».

Dans un code ou le « refactoring » n’a pas été suivi, on se retrouve bien souvent dans cette situation.
Dans le monde logiciel,  il est nécessaire de ménager du temps pour l’analyse, la réorganisation et le maintien de la logique du logiciel.
Plus la constatation d’une réorganisation nécessaire sera reportée, plus elle sera coûteuse en temps et en énergie.
« Le temps ne respecte pas ce qui se fait sans lui. » [Paul Morand]
 Pour conclure :

Newsletter