Quelle équipe de développement logiciel ne se plaint pas à un moment ou à un autre de sa « dette technique » ? Mais comme le dit le sage, il faut prendre soin de nos pensées parce qu’elles deviennent nos mots, et nos mots deviennent nos actions. Avec cette manie d’aborder ce sujet systématiquement sous l’angle d’un problème économique, à quoi nous condamnons-nous ? Au désespoir, car il faut se souvenir que l’économie est appelée la « dismal science », la science lugubre.

Changeons, ne serait-ce que pour une fois, de point de vue, et revisitons un extrait de Richard Gabriel, un pionnier un peu oublié du mouvement des « patterns ». Il est tiré de « Patterns of Software » et intitulé « Habitability and Piecemeal Growth » (page 9).

Vous n’avez pas envie d’habiter dans une maison sale ou mal conçue — une maison où il faudrait traverser deux couloirs pour vous rendre de la chambre à la salle de bains, où les toilettes seraient au milieu de la cuisine.

L’habitabilité, c’est la caractéristique d’un environnement dans lequel il est agréable et naturel de passer du temps. Elle peut s’opposer à des notions séduisantes mais parfois dangereuses, telles que l’élégance et la symétrie.

La Tour Eiffel est un monument élégant, ce n’est pas un bâtiment habitable. Les maisons de Le Corbusier ont fait école, mais la propriétaire de l’une d’elle dut se résoudre à l’assigner en justice, se lamentant : « Il pleut dans l’entrée, il pleut dans la rampe et le mur du garage est absolument trempé. D’autre part, il pleut toujours dans ma salle de bains qui est inondée à chaque pluie. »

Pour Richard Gabriel, c’est la nature-même d’un logiciel que de croître peu à peu. Ce n’est pas un monument grandiose que nous souhaitons, c’est une petite bicoque qui grandit par extensions successives, à l’exemple d’une ferme : d’abord le corps de ferme et une grange, avec le temps on y ajoutera une étable, un garde-manger, on finira par relier la ferme à la grange par une extension couverte… ce n’est pas une croissance anarchique mais maîtrisée, guidée selon des schémas familiers.

Ce que j’apprécie dans ce passage et dans les réflexions qu’il a inspirées (plusieurs pionniers du mouvement Agile ont puisé à cette source), c’est de nous ramener à l’évidence : le code ce n’est pas seulement quelque chose qu’on produit. C’est quelque chose qu’on habite — quand on développe, c’est un « endroit » où nous passons la plus grande partie de notre temps. La façon dont on en prend soin, individuellement ou collectivement, en dit autant sur nous que la façon dont nous prenons soin de notre maison.

Assis à côté d’un développeur, j’écoute celui-ci m’expliquer les secrets d’une méthode un peu compliquée qui réalise des calculs financiers au sein d’une application de gestion de portefeuilles.

— Bon évidemment, ne regarde pas trop cette partie-là, c’est un peu de la m… Ah la la, comment ils ont appelé cette fonction déjà? Je ne me souviens plus, mais ce n’est pas ça… Ça n’est pas là non plus… c’est n’importe quoi.

— Quels sont les standards de l’équipe en matière de noms de fonctions ?

— On a pas de standard ! Chacun fait comme il veut, c’est pour ça que c’est dans cet état-là…

Comme notre appartement ou notre maison, le code comme habitat présente une certaine tolérance pour le désordre. En allant chercher une facture dans le tiroir du bureau, je bute sur le jouet du petit, sans y faire trop attention, en me notant de garder du temps pour remettre le salon en ordre avant le dîner. Il n’y a là pas matière à discuter la place d’une facture ou celle d’un camion miniature, parce que le rangement fait partie de notre vie dans la maison et que les discussions structurantes qui le régissent n’ont lieu qu’à de rares occasions, à l’achat d’un meuble ou lors du réaménagement d’une pièce.

En revanche, on peut apparemment vivre ensemble dans un code en équipe, tout en n’étant pas d’accord sur l’endroit où ranger chaque chose. En cherchant à m’expliquer le « fonctionnel » sur cette partie de l’application, mon interlocuteur bute sur un problème de nommage qui l’empêche d’aller à l’essentiel et sa réaction semble indiquer un problème structurel d’équipe tel qu’aucun refactor/rename method n'en viendra à bout.

Et pourquoi ne pas refactorer ? On a essayé, mais sans tests, on casse la prod’ et on doit revenir en arrière. Alors, écrire des tests ? C’est impossible, ou bien trop cher. Le code est trop couplé.

Ce n’est pas une fatalité : pour telle autre équipe qui pratique la propriété collective du code et le refactoring en continu, le code est un habitat à la fois plus flexible et plus aligné aux standards. Une règle presque implicite de ranger derrière soi semble opérer sur le code. Deux salles, deux ambiances !

Kent Beck a souvent fait remarquer que dans eXtreme Programming, les pratiques se renforcent mutuellement, c’est-à-dire que l’efficacité de l’une contribue à l’efficacité de plusieurs autres et réciproquement.

La mauvaise nouvelle, c’est que si des pratiques comme par exemple tests en isolation, refactoring continu, propriété collective du code se renforcent mutuellement, réciproquement, leur absence produit une aggravation combinéede l’état de la base de code. Nous ne pouvons pas habiter ce code ensemble parce que nous ne pratiquons pas la propriété collective du code, parce que le code est trop fragile et difficile à comprendre pour être refactoré par chacun de manière routinière, ceci parce que le code manque de tests isolés, ceci à son tour parce que les modules et les classes y sont trop fortement couplés… parce que nous ne pouvons pas refactorer, ad nauseam.

La mélancolie des passions

Nous chloroforme

Faut refaire toute l’installation

Rien n’est conforme

— Alain Souchon

Les expressions ne manquent pas pour désigner une base de code devenue inhabitable aux yeux de ses contributeurs : c’est une usine à gaz, un gros tas de boue, un bousin. À la question : qu’est-ce qu’il faudrait faire à ton avis ? La réponse ne se fait pas attendre : il faudrait tout refondre. Comme c’est impossible, on prend sur soi, ou on s’en va.

C’est pour cela qu’il faut « tout refaire » : l’action adjacente, le petit geste qui répare, la prochaine amélioration, sont devenus objectivement impossibles, ou à tout le moins sont ressentis comme dérisoires face à l’ampleur du désordre. Logique dangereuse — parfois : « il n’y a pas de planète B », l’option de quitter son habitat n’existe tout simplement pas.

Si le code est un habitat, nous devons nous intéresser à lui appliquer une logique — ou une politique — d’habitat. Qu’est-ce qui fait de ma maison un espace habitable ?

• Elle repose sur une architecture qui la rend structurellement habitable.
• On y pratique le nettoyage, le rangement, le réaménagement, et ces pratiques se renforcent mutuellement.
• Ces pratiques sont elles-mêmes sous-tendues par la relation de renfort mutuel entre ses habitants.

« Remember, code is your house, and you have to live in it. »

― Michael C. Feathers, Working Effectively with Legacy Code

Pour aller plus loin

• Le nouveau projet de Kent Beck « Tidy First » est en soi une allusion à la notion de rangement (tidy) pour préserver l’habitabilité de son code
• Le demi-cercle, un roman de Christophe Thibaut, habité par cette métaphore

‍