La dette technique et le bateau de Thésée

Qu'est ce que la dette technique ?

Si vous tra‌vaillez dans le domaine du dé​​velop‌pement vous avez probablement déjà entendu parler de la fameuse "dette technique". Ce terme est assez étrange mais permet de se faire une bonne idée de ce que cela désigne. En effet, dans note milieu, la dette se révèle lorsque le coût des correctifs, des adaptations et de maintenance du projet devient supérieur au cout initial du projet. D'un point de vue plus pratique, elle désigne couramment le code à risque dans un projet. Un code à risque peut répondre à (au moins) une des conditions suivantes :

• ‌un spectre fonctionnel mal défini : un code prévu pour une fonctionnalité dont tous les cas d'entrée n'ont pas été prévus, et qui va probablement générer un bug lorsqu'un cas non prévu va survenir.
• ‌un code difficilement évolutif : un code pour lequel on sait déjà qu'en cas d'évolution fonctionnelle, les interventions sur cette partie vont être particulièrement chronophages, voire impossibles.
• ‌un code surdimensionné : un code difficilement lisible, particulièrement long et incompréhensible par un développeur tiers.
• ‌des technos obsolètes : un code qui dépend d'une librairie ou d'une technologie à durée de vie limitée.

Il faut aussi noter que quand on parle de dette technique sur un projet, c'est bien que quelqu'un a conscience à un moment donné que lui ou une autre personne a fait de la daube. En d'autres termes, elle est invoquée lorsqu'on a conscience d'un code à risque. Ce qui veut dire également que quand quelqu'un vous dit que son projet n'a pas de dette technique, ce n'est pas nécessairement qu'il n'y a pas de code à risque, c'est qu'il n'en a peut-être pas conscience... et c'est encore pire.

C'est grave docteur ?

La dette technique est inévitable dans un projet qui n'a pas de durée de vie limitée. En revanche, si votre projet a un temps de publication limité, peu importe qu'il y ait un code à risque si celui-ci concerne la difficulté d'évolution. Si le projet est abandonné demain, il ne sert à rien de passer 3 jours à l'améliorer (sauf si vous êtes un artiste, ou immortel auquel cas le temps n'a pas la même valeur pour vous).
Mais, le défaut de qualité que représente la dette technique est crucial lorsqu'il s'agit d'un projet qu'on souhaite voir vivre.

Comme son nom l'indique, la dette technique peut s'avérer particulièrement coûteuse. C'est une épée de Damoclès, un caillou dans la chaussure, qui va progressivement embourber votre projet dans une bouillie d'inertie. Pourquoi ? Tout simplement pour les raisons que j'ai évoquées plus tôt :

• ‌un spectre fonctionnel mal défini va augmenter le risque de dysfonctionnement donc de temps non prévu qui devra être passé à la résolution de bugs qui auraient pu être évités, d'autant plus qu'il est toujours difficile de redéfinir un spectre fonctionnel sur de l'existant.
• ‌un code difficilement évolutif va vous coûter plus cher lorsque le projet nécessitera l'ajout d'une fonctionnalité. Si vous devez intervenir à 20 endroits pour ajouter un seul élément, vous rendrez fous vos développeurs.
• ‌un code surdimensionné va obliger vos développeurs à prendre le temps de comprendre l'ensemble de la partie posant problème. Et 1000 lignes à lire et comprendre prennent plus de temps que 10 lignes qui font la même chose.
• ‌des technos obsolètes vont forcément vous exploser à la figure à un moment donné, pour des raisons de sécurité, d'infrastructure ou tout simplement d'évolution fonctionnelle. Souvenez-vous de Flash (ouais ok c'était facile).

Comment l'éviter ?

Comme dit plus tôt, la dette technique est inévitable. Il n'existe pas de projet parfait à sa sortie, qui reposerait sur des technos sûres et performantes, sans nécessiter d'évolution sur le court, moyen ou long terme. A la limite, cette dette est même souhaitable. Elle montre qu'un projet vit et évolue, donc vous ne bossez pas pour rien. Cependant, si elle est souhaitable, elle ne doit pas être pour autant négligée, elle ne doit pas devenir envahissante. La meilleure façon d'éviter la dette technique c'est de l'accueillir et de préparer son arrivée. Et comment faire cela ?

Solution 0 - Simplicité, efficacité : fuyez !

Fuyez !!! Trouvez-vous un prestataire qui gèrera la TMA, un stagiaire ou toute autre personne que vous détestez pour gérer les soucis. Changez d'identité, partez vous réfugier en Corée du Nord, peut-être que personne ne vous retrouvera.

Solution 1 - Simplicité et inefficacité : les devs d'abord, on abandonne le navire

Une autre solution est celle qui se présente quand il est trop tard, on abandonne le projet et on en recommence un autre avec le même spectre fonctionnel mais un code à jour. Cela consiste à stopper toute évolution sur le projet en cours. On ne traite plus que les bugs, les dysfonctionnements. Tout ce qui concerne des évolutions fonctionnelles voire des bugs mineurs ne sera plus traité.

En revanche, en parallèle, on commence une nouvelle version à jour du projet qui remplacera l'ancienne. Tout cela parce qu'on pense qu'on va prendre en compte toutes les erreurs de la précédente version. En soit c'est une technique radicale qui supprime une dette trop importante à résorber, mais en revanche, si on ne traite pas le problème de fond, on est juste en train de se créer une nouvelle dette, jusqu'au prochain abandon.

En effet, ce n'est pas parce qu'on a l'intention de faire les choses bien à un instant T qu'on ne crée pas de dette technique. Ce qu'on fait de bien aujourd'hui est amené à devenir de la merde dans le futur. C'est d'ailleurs ce qu'il s'est passé pour le projet qu'on est en train d'abandonner. A sa sortie celui-ci était probablement le fleuron de votre flotte de projets, et puis c'est au cours du temps qu'il s'est révélé être obsolète, parce qu'on n'a pas pris soin de lui, parce qu'on a réglé les problèmes au jour le jour sans prendre en compte l'avenir du projet.

Solution 2 - La conservation : on sort l'huile de coude

La conservation peut être illustrée par l'expérience de pensée du bateau de Thésée, qui veut que les Athéniens aient entretenu le bateau mythique de Thésée pendant une période exceptionnelle. L'histoire veut que, pour le conserver dans le meilleur état, les Athéniens remplaçaient au cas par cas chaque clou, chaque planche usée ou obsolète de sorte qu'au final, aucun élément du bateau n'était original, mais l'ensemble restait parfaitement fonctionnel. Au-delà des questions philosophiques de la chose (est-ce toujours le même bateau ou pas ?), il en ressort surtout que d'un point de vue technique, c'est le seul moyen fiable de conserver un projet dans le meilleur état. Evidemment, ceci a un coût, qui va être répercuté sur toute la vie du projet, mais il permet de ne pas avoir à débloquer un énorme budget à un moment donné pour tout restaurer dans un temps compté et pour combien de temps ?

C'est la solution la plus la contraignante mais pour autant la plus efficace à long terme. Il s'agit, à la différence de la solution d'abandon, d'accueillir la dette technique tout au long de la vie du projet et pas uniquement quand celui-ci le nécessite. Il n'y a pas de remède magique contre la dette technique mais plutôt un ensemble de bonnes pratiques qui apportent une thérapie douce et régulière à votre projet concernant les points critiques :

• un spectre fonctionnel bien défini. Effectivement ce point est particulier parce qu'il n'incombe pas au développeur de définir le spectre fonctionnel. En revanche, c'est au développeur de mettre en place l'ensemble des besoins de tous les acteurs du projet. Dans ce sens, il fait aussi office de sentinelle et doit être capable de s'assurer que tous les besoins peuvent être traités, qu'ils peuvent cohabiter. Et dans cette approche il doit aussi prendre sa longue vue et voir plus loin, et, le cas échéant, mettre en lumière les fonctionnalités nécessaires qui n'ont pas encore été identifiées, voire les évolutions possibles à court, moyen ou long terme. Il ne relève pas du rôle de développeur de mettre en place ces fonctionnalités fantômes. En revanche il est nécessaire que le développeur alerte la chaine décisionnelle à ces sujets. A ce propos, je vous renvoie vers l'article sur le travail en équipe qui fait écho à ce point.
• un code facilement évolutif. Il faut préparer son projet aux évolutions dès la phase de conception. A ce sujet, je vous renvoie vers cet article qui traite de l'abstraction. Cette approche va vous permettre d'isoler les fonctionnalités. Une fonctionnalité isolée peut évoluer beaucoup plus sereinement, sans craindre d'effet de bord. De la même manière, il est important d'avoir une approche modulaire (et là je vous renvoie vers l'article sur la modularité) afin de fournir des points d'entrée fiables contre toute altération d'une fonctionnalité existante. Toutes ces prises en compte peuvent sembler overkill durant la phase de conception, mais elles vont vous faire gagner énormément de temps dans le futur.
• un code léger. C'est assez subjectif, mais il est important qu'un code soit propre et léger. Par là, j'entends qu'il doit être lisible donc doit respecter de bonnes pratiques (les codings standards) et doit être au maximum commenté. Il n'y a pas de technique infaillible qui permette de respecter cela si ce n'est une prise de conscience des développeurs (et un peu de code review). A savoir aussi que le travail en groupe permet d'améliorer les performances des développeurs car on ne garde systématiquement que le meilleur du travail partagé. Je vous renvoie sur les bonnes pratiques que j'ai déjà évoquées dans cet article.
• des technos à jour. C'est important de tenir ces dépendances à jour. En effet, outre les problèmes de sécurité de certaines librairies, il faut aussi avoir conscience que les évolutions des librairies tierces vont vous permettre de simplifier votre code, proposer des évolutions, voire même vous désengager de la maintenance de certaines fonctionnalités si celles-ci ont, depuis, été développées par d'autres personnes. Il n'est pas évident de mettre à jour toutes les technos, notamment quand ces dépendances sont structurelles. Cependant, il faut les envisager et peut-être parfois ne pas mettre tous ses oeufs dans le même panier, c'est l'avantage des architectures microservices.

Pour une plus grande fiabilité, tout ceci ne doit pas être traité à la volée mais bien appréhendé de manière régulière. C'est à dire qu'il faut se donner du temps régulier de vérification et de recherche pour améliorer la viabilité du projet, même si aucune alerte n'est levée. C'est un petit temps de maintenance à prévoir qui peut vous éviter bien des catastrophes.

Conclusion

Pour finir, on se rend compte que le meilleur moyen d'éviter d'être surchargé par la dette technique c'est de l'accepter et de la prévenir. La considérer dès la conception du projet est un atout majeur pour la rendre moins handicapante. Pour ça, les éléments de la solution 2, à savoir un spectre fonctionnel bien défini, un code facilement évolutif, un code léger et des technologies à jour, sont des éléments qui vont réduire son impact. Ce sont de bonnes pratiques, mais le plus dur reste l'identification des éléments posant problème avant qu'ils ne le fassent, admettre la dette technique potentielle, ainsi que trouver le temps et la volonté de travailler sur un projet régulièrement et de manière pro-active.

P.S.

Vous remarquerez que je ne parle pas de test ici. En effet, les tests sont nécessaires et une très bonne pratique bien sûr, cependant ils ne permettent pas d'identifier une dette technique. Ils permettent d'identifier des bugs, ce n'est pas la même chose. Les tests nous permettent de vérifier ce qu'on sait déjà. La dette technique est justement ce qui correspond à identifier ce qu'on ne sait pas encore. C'est pourquoi ils sont décorrélés de la notion de dette technique.