Une affordance trompeuse assez légère, presque anecdotique, mais qui faisait parti de la liste d'origine de cette série.

Parlons refactorisation, ou plutôt parlons de l'abus de l'usage du terme. De nos jours, toute modification de code sans perspective d'évolution fonctionnelle est régulièrement appelée refactorisation, parce qu'il est connu qu'il y a eu une écriture initiale en des temps immémoriaux, et qu'il n'advient subséquemment qu'une suite sans fin de refactorisations pour l'amener vers la fameuse qualité. D'ailleurs Ward Cunningham n'a-t-il pas parlé lui-même de la refactorisation comme outil de remboursement de la dette technique ? Il le fait, a raison, parce que c'est Ward, il en a le droit.

Faisons un petit tour par l'origine du terme factorisation : il nous vient des mathématiques, plus précisément de l'algèbre, et il signifie l'opposé du terme développement. Coïncidence ? Beauté d'un vocabulaire spécifique à un domaine ? Poésie de l'informatique ? Sans rentrer dans les détails de la distributivité, on peut donner quelques exemples accessibles : 35 + 45 = 5 x (7 + 9), le 5 a été mis en facteur ; 18 + 24 = 3 × (6 + 8) = 6 × (3 + 4) = 2 × (9 + 12). Toutes ces formes sont strictement équivalentes, elles représentent le même nombre. Cela fonctionne aussi en l'exprimant sous la forme d'un dérivé de l'algèbre nouvelle : (a + b)² = a² + b² + 2 × a × b, cette forme factorisée à gauche, et développée à droite, est tellement remarquable qu'elle fait partie de la famille des identités remarquables. Remarquable non ? Bref, l'intérêt du principe de factorisation c'est que cela fonctionne, quelles que soient les valeurs auxquelles ont l'applique, car c'est le principe même de mise en facteur qui est rigoureusement prouvé.

Les anglophones sont donc partis sur cette thématique d'effectuer une nouvelle mise en facteur du code, d'abord afin de le compacifier et d'éviter les doublons, puis pour désigner toute opération de restructuration que l'on n'a pas vraiment besoin de tester pour savoir qu'elle ne changera pas le comportement du logiciel. Et ils leur ont donné le nom de refactoring, non pas en référence à l'usine factory, encore moins à la fabrication to manufacture et à l'usinage to machine, mais bien à la mise en facteur to factor. Mais ça, les québecois sont complètement passés à côté en proposant réusinage, sans doute pour se caler sur les français proposant le cache.

Les techniques de refactorisation, qui par nature garantissent l'absence de modification du comportement, ne peuvent donc être que très précisément définies et en nombre relativement restreint. Et pourtant le terme est devenu synoyme avec le temps de n'importe quelle opération de retravail du code. Qui va s'en plaindre me direz-vous, à part quelques puristes sycophantes comme moi-même ? Dans ce cas précis, c'est une personne que nous avons déjà rencontré dans cette série sur les affordances trompeuses, en la personne de Martin Fowler. Le livre Refactoring : improving the design of existing code écrit par celui-ci est sorti en 1999, et a grandement contribué à faire connaître ces techniques, et est considéré par certains comme la bible sur la refactorisation. Oui, le même Martin Fowler qui a détruit toute la valeur de la métaphore de la dette technique, se plaint du mésusage du terme refactoring dans cet article de 2004. On peut y lire :

Je réalise que je suis sans doute en train de mener un combat perdu d'avance, mais je veux préserver la précision de la définition de la refactorisation. Il peut y avoir d'autres bonnes techniques pour restructurer, mais elles sont différentes. J'aimerais que nous soyons tous au clair sur ce que cela signifie quand nous utilisons ce mot.

Ah Martin, si seulement tu savais !

Vous pouvez trouver le reste de la série sous l'article d'introduction.