Dette technique : ma bibliothèque Rust a désormais été transformée en CDO

Dette technique : ma bibliothèque Rust est désormais un CDO

• Pour plaisanter sur la dette technique, on dit parfois que s’il existe de la dette technique, il devrait aussi exister des produits dérivés pour la traiter.
• L’écosystème Rust a trouvé une solution qui donne l’impression de titriser la dette technique.
• Par exemple, une bibliothèque stuff dépend d’une autre bibliothèque learned-rust-this-way, mais l’auteur de learned-rust-this-way s’en désintéresse et les problèmes commencent à s’accumuler.

La réalité de la dette technique

• learned-rust-this-way est considérée comme de la dette technique : elle ne provoque pas de problème direct, mais reste malgré tout une dette.
• À un moment donné, quelqu’un se rend compte que learned-rust-this-way est une dette, n’arrive pas à joindre l’auteur d’origine, et elle est ajoutée à la base de données RUSTSEC.
• RUSTSEC, en tant qu’agence de notation, classe cette dette comme un déchet, ce qui entraîne l’échec des CI (intégration continue) de nombreuses personnes.

Comment traiter la dette

• En tant que mainteneur de stuff, le stress augmente lorsque les utilisateurs soulèvent des problèmes liés à l’usage de learned-rust-this-way, et l’on vous demande d’agir pour traiter cette dette.
• Migrer vers une alternative est une option, mais dans ce cas aucune des alternatives n’est vraiment séduisante.
• Forker learned-rust-this-way revient à faire face aux mêmes exigences : ce n’est qu’une solution temporaire qui ne résout pas réellement le problème.

La solution qui fonctionne vraiment

• Si l’on fusionne ce code dans sa propre bibliothèque, cette dette technique considérée comme un déchet se retrouve soudainement notée « AAA ».
• On ne touche plus au code, on dissimule le fait qu’il a été fusionné, et on continue à maintenir la bibliothèque comme avant : le monde continue de tourner.
• En intégrant yaml-rust directement dans insta, celui-ci est devenu un assemblage de code insta et yaml-rust, ce qui a permis de faire passer cette dette technique à une note AAA.

L’avis de GN⁺

• Cet article compare avec humour la dette technique à des produits dérivés financiers pour expliquer avec esprit des problèmes qui surviennent dans le développement logiciel.
• La dette technique est un problème fréquent en développement logiciel, et cet article propose aux développeurs une manière créative de la gérer.
• Des systèmes d’évaluation comme RUSTSEC dans l’écosystème Rust peuvent aider les développeurs à estimer la stabilité des bibliothèques, tout en pouvant aussi générer du stress inutile.
• Fusionner le code pour résoudre la dette technique peut constituer une solution temporaire, et une stratégie de maintenance durable reste nécessaire à long terme.
• Dans ce type de situation, on peut envisager plusieurs solutions, comme une maintenance pilotée par la communauté, la co-maintenance de projets open source, ou la recherche d’une version alternative de la bibliothèque.

[GN⁺]

Avis sur Hacker News

• L’auteur du parseur YAML le plus populaire a soudainement abandonné le projet et l’a marqué comme deprecated et unmaintained. Cela s’est fait sans avertissement ni désignation d’un autre mainteneur ; le paquet reste fonctionnel, mais comme il est encore utilisé par plus de 4 000 autres crates, les outils d’audit et de mise à jour automatique signaleront l’utilisation d’une crate non maintenue.
• Pour ceux qui étaient déroutés par l’acronyme CDO, il s’agit vraisemblablement de « collateralized debt obligation », puisque le mot « collateralized » est utilisé à plusieurs reprises.
• Si les chemins de code vulnérables ne peuvent pas être exécutés ou atteints depuis des bibliothèques externes, alors cela devient un chemin de code sûr. Le vendoring de bibliothèques fournit les outils pour attaquer le code et, si la couverture de test de sa propre bibliothèque est suffisante, il est possible d’exécuter des outils de couverture de code sur la bibliothèque importée. Modifier une bibliothèque importée peut être difficile, mais supprimer les parties inutiles peut être relativement simple. Bien sûr, cela dépend de la structure de la bibliothèque importée.
• Un ancien analyste quantitatif devenu économiste félicite l’auteur pour avoir correctement employé le terme « Collateralized Debt Obligation ». Il aimerait écrire un article sur la « dette technique », mais estime que la métaphore de la « dette » ne convient pas bien à ce concept. L’expression « code à haute viscosité » serait peut-être meilleure. Le code semble doté d’une forte inductance, car il n’est pas facile à modifier pour l’adapter à de nouvelles fonctionnalités.
• À propos du fait que la « junk tech debt » se retrouve soudain notée « AAA », l’auteur semble vouloir dire qu’un même code ne peut pas avoir une meilleure notation de dette avant et après avoir été vendorisé. Mais cela ne considère que la valeur du code lui-même et passe à côté de la partie la plus importante de la proposition de valeur globale. Le mainteneur qui vendorise le code en devient désormais propriétaire, et un mainteneur actif qui récupère du code d’un projet mort augmente sa valeur, car il y a désormais un humain capable de répondre aux issues, de relire les pull requests et de corriger les bugs.
• Le même schéma a aussi été observé dans l’écosystème JS npm. Npm audit lance surtout des alertes exagérées sur des problèmes de sécurité et, tant que la licence le permet, c’est l’un des moyens les plus fiables d’échapper aux problèmes absurdes transmis par les utilisateurs.
• C’était une chance d’avoir forké yaml-rust et de l’avoir réécrit en pur Rust pour créer yaml-rust2. Ce fork passe entièrement la suite de tests YAML et affiche de meilleures performances dans les benchmarks. La migration semble également simple. Au final, le problème demeure : nous dépendons toujours d’autres personnes qui fournissent actuellement un travail gratuit, sans aucune garantie qu’elles continueront à le faire pour toujours.
• Si un gestionnaire de paquets basé sur les sources n’impose pas au registre le droit légal de reprendre de force la maintenance des paquets publiés, il fera face à des problèmes terribles : abandon, modifications malveillantes, suppressions malveillantes, usurpation, etc. Pour les paquets jugés suffisamment importants par la communauté, il faut un moyen de retirer l’entrée du registre des mains du propriétaire d’origine et de la remplacer par un fork.
• Si le code fonctionne et fonctionne ainsi depuis des années, en quoi est-ce gênant qu’il ne soit plus maintenu ? S’il n’a pas besoin d’être corrigé et que l’on connaît ses limites comme ses capacités, ce n’est pas un problème. Le code ne se dégrade pas tout seul. Il n’y avait aucun souci à réutiliser ou intégrer à plusieurs reprises du code vieux de plusieurs décennies.
• Le vendoring des dépendances est la solution. C’est ce qui est fait depuis 20 ans pour presque toutes les dépendances « terminées » dont le développement et la maintenance se sont ralentis.