Les logiciels au sang froid
- En 2004, l’auteur, alors étudiant en informatique, assiste à un cours d’histoire naturelle où le professeur montre un bébé tortue peinte congelé.
- Cette tortue fait partie des rares espèces capables de survivre à l’état congelé, un animal à sang froid capable de réguler son métabolisme à basse température.
- En observant la tortue bouger lentement et reprendre vie pendant le cours, il approfondit sa compréhension des animaux à sang froid.
La dichotomie des projets logiciels
- Les projets logiciels aussi peuvent être divisés entre projets à sang chaud et projets à sang froid.
- Les projets à sang chaud nécessitent une activité continue, et des problèmes apparaissent lorsque cette activité s’arrête.
- Les projets à sang froid peuvent rester inactifs pendant un certain temps et reprendre ensuite exactement là où ils s’étaient arrêtés.
Le logiciel à sang froid du blog
- Le logiciel qui fait tourner le blog de l’auteur est un logiciel à sang froid.
- Démarré il y a 12 ans, ce projet est simple, ne dépend pas de services externes, et toutes ses dépendances sont incluses dans le dépôt du projet.
- À part quelques petites améliorations, il fonctionne très bien sans modification et devrait encore fonctionner dans 12 ans.
L’avis de GN⁺
- Le concept de logiciel à sang froid a un impact important sur la durabilité et la maintenabilité d’un projet.
- Cet article apporte un éclairage sur la manière dont le choix de la stack technique influence la longévité d’un projet.
- L’expérience de l’auteur offre aux développeurs logiciels une leçon sur la façon de construire des systèmes stables sur le long terme.
1 commentaires
Avis Hacker News
Dans l’écosystème Node et JavaScript, il existe le framework web Express. Sa branche majeure actuelle, la 4.x.x, a plus de 10 ans et est téléchargée plus de 17 millions de fois par semaine. Il lui manque certaines fonctionnalités et ce n’est pas ce qu’il y a de plus performant, mais de nombreux développeurs le préfèrent parce qu’il permet un développement rapide et stable, et qu’il est possible de planifier sur le long terme sans s’inquiéter des changements d’API ou du manque de correctifs de sécurité. Go offre une stabilité encore meilleure grâce à sa vaste bibliothèque standard et à sa promesse de compatibilité, au point que des programmes vieux de plus de 10 ans peuvent encore s’exécuter.
Si un logiciel fonctionne bien sans mise à jour, c’est qu’il a été bien conçu dès le départ. C’est relativement plus simple pour un logiciel utilisé à titre personnel, car les préférences changent peu. En revanche, quand on écrit un logiciel destiné à d’autres personnes, les besoins peuvent varier et des problèmes imprévus peuvent surgir. Par exemple, il peut planter lors du traitement de gros fichiers, et il faut alors parfois réécrire la moitié du logiciel pour corriger le problème. C’est le principal contre-argument à l’idée selon laquelle un logiciel qui change peu serait forcément meilleur.
Python est un mauvais exemple à cause de ses changements incompatibles répétés. À l’inverse, Go ou Java permettent encore à du code vieux de 10 ans de bien fonctionner avec des outils modernes. Perl est un exemple encore meilleur : du code vieux de 30 ans fonctionne toujours très bien.
Je travaille sur des mainframes IBM (z/OS). IBM est ce qui se fait de mieux en matière de maintien de la rétrocompatibilité. Microsoft (Windows) arrive en deuxième, et l’ABI de Linux (noyau) en troisième. La plupart des autres systèmes souffrent d’un problème courant dans l’OSS, où l’on ne veut pas consacrer de temps au maintien de la compatibilité.
Les dépendances peuvent donner du « sang chaud » à une application, mais Docker ou la conteneurisation peuvent atténuer ce problème dans une certaine mesure. Quand je choisis des bibliothèques pour un projet, je fais suffisamment de recherches pour vérifier qu’il s’agit de bibliothèques à « sang froid ».
Beaucoup d’ingénieurs regardent la date du dernier commit quand ils cherchent une bibliothèque sur GitHub. Ils pensent souvent que plus le commit est récent, mieux le projet est maintenu. Pourtant, trouver un projet archivé, stable depuis longtemps et sans bugs, c’est un peu comme dénicher un joyau caché dans une boutique d’occasion.
Je maintiens mon propre side project. Je l’ai commencé il y a 12 ou 13 ans, puis je l’ai réécrit en PHP, Laravel et Symfony. Cela m’a énormément appris sur la manière de faire durer un projet dans le temps. Par exemple, j’ai saisi des occasions de simplifier, en passant de Vagrant à Docker, puis de Vue + Axios + Webpack à Htmx. Récemment, je l’ai mis à niveau vers PHP 8.2 et Symfony 7, et j’y ai intégré des fonctionnalités basées sur ChatGPT.
Je suis lassé des applications mobiles de ces dernières années qui nécessitent quelques heures de correctifs. L’auteur décrit son générateur de site statique comme étant à « sang froid » ; il tourne sous Python 2, mais il devient de plus en plus difficile d’installer Python 2.
Un SDK que j’ai écrit en 1994-95 a été utilisé jusqu’à mon départ de l’entreprise en 2017. Il était écrit en ANSI C, et ce que j’ai écrit en PHP (5) fonctionne aussi très bien sous PHP 8.2. Mais ce sont des choses ennuyeuses, avec un faible potentiel de buzz.
Au-delà de ce qui est mentionné dans l’article, il est également important d’avoir un modèle de menace intrinsèquement sûr. Par exemple, un site web complet doit continuellement faire face aux attaquants, aux spambots, etc., et relève donc intrinsèquement du « sang chaud ». À l’inverse, des pages statiques comme Tiddlywiki sont bien meilleures, car elles n’ont pas besoin d’être publiées sur le web et parce que le navigateur est une plateforme très stable.