Discussion :

[Bill Fassinou]

La plupart des codes ne sont-ils édités que par une seule personne et ont-ils une existence brève ? Oui,
car ils sont souvent mis à jour et parfois supprimés, selon Derek Jones

Un code source a-t-il une existence brève ? Selon Derek Jones, un développeur informatique, c’est ce qu’on observe bien souvent. Celui-ci soutient que, lorsqu’un code source est écrit, la majeure partie du code n'est jamais modifiée et ne reste en place que pendant très peu de temps. Dans un billet de blogue, Jones estime qu’un investissement dans le code source est une perte à terme, à moins que les rendements ne soient spectaculaires. A-t-il raison de penser cela ? Et les codes sources dans les grandes organisations, connaissent-ils aussi ce sort ?

Selon Jones, il existerait de nombreuses preuves de ce qu’il dit. Cela inclut un livre de génie logiciel qu’il dit avoir écrit, un livre basé sur des preuves et des articles de blog sur la durée de vie des systèmes logiciels. Il a aussi ajouté comme preuve le temps de survie des distributions Linux. Il faut noter que l’année passée, au moins deux distributions Linux se sont vues fermées ou abandonnées par leurs développeurs. Il y a l’exemple de Scientific Linux et Antergos qui ont annoncé l’arrêt de leur développement en mai dernier.

Pour Jones, la durée de vie est brève parce que les paquets sont mis à jour et les tiers modifient ou suppriment les API. Il souligne que les personnes qui pensent qu'un code source a une longue durée de vie souffrent d'un préjugé de survie. En d’autres termes, les programmes qui sont activement utilisés pendant de nombreuses années sont très rares. Toutefois, si la durée de vie des codes sources est courte, Jones rappelle qu’il existe quand même des avantages et des inconvénients qu’on peut noter.

Dans son argumentaire, Jones a déclaré que l’un des avantages d'une courte durée de vie est que la plupart des erreurs de codage ne vivent pas assez longtemps. Le code contenant l'erreur est supprimé ou remplacé avant que quiconque ne remarque l'erreur. Par ailleurs, l’une des conséquences négatives de la courte durée de vie de code source serait que tout investissement réalisé dans l'espoir d'économiser sur les coûts de maintenance futurs est perdu.

« Lorsque de nombreux programmes ne vivent pas assez longtemps pour être maintenus, ceux qui ont une longue durée de vie doivent servir à payer les investissements initiaux effectués dans tout le code source qui a rapidement disparu », a-t-il expliqué à propos. En outre, il a présenté des données d’études sur les modifications des fonctions selon lesquelles environ 60 % des fonctions ne sont modifiées que par une seule personne. Sur la base d'une étude de l'historique des changements de fonctions dans Evolution, c’est 114 485 changements de fonctions sur 10 ans.

D’après une étude de l’éditeur Apache sur le même thème, c’est 14 072 modifications sur 12 ans. Cependant, tout le monde n’est pas d’accord avec Jones. Quelques-uns estiment qu’il n’a pas assez de preuves qui justifient ce qu’il dit. Ils pensent que les données utilisées par Jones ne sont pas représentatives du monde logiciel dans son ensemble. Les distributions Linux sont également suspectées d'être non représentatives. Ils estiment qu'un code vit pendant de très nombreuses années. La plupart du temps, les développeurs passent 70 % de leurs temps à modifier le code existant et 30 % à écrire un nouveau code.

Pour d’autres, Jones serait peut-être arrivé à une conclusion différente avec un échantillon tout à fait aléatoire de tous les logiciels. Les exemples qu’ils ont cités sont nombreux. Il y a l’exemple de la pile Web, les systèmes informatiques embarqués, les systèmes bancaires, les systèmes militaires, les systèmes gouvernementaux, etc. Pour certains, Jones a raison. À titre illustratif, ils citent l’itération très rapide que subit les projets open source. D’après ces derniers, chaque partie de ces projets ou de ces logiciels open sources est également souvent laissée à la charge d’une seule personne.

Enfin, le poste de Jones souligne beaucoup de préoccupations sur la façon dont les codes sources sont écrits, suivis et maintenus. Est-il vrai que le code source a une courte durée de vie ? Si oui, y a-t-il un risque pour les projets informatiques à l’avenir ?

Source : Derek Jones

Et vous ?

Quel est votre avis sur le sujet ?
Partagez-vous l'opinion de Jones ? Pourquoi ?
De votre expérience, le code d'une application a-t-il une courte durée de vie ? Si oui, y a-t-il un risque pour les projets informatiques à l’avenir ?

Voir aussi

Scientific Linux et Antergos annoncent l'arrêt du développement de leurs distributions Linux. Linux Mint pourrait leur emboîter le pas

Pourquoi Linux n'a-t-il pas de succès sur desktop ? Entretien avec Mark Shuttleworth, fondateur et PDG de Canonical, éditeur d'Ubuntu

Tesla rend publique une partie du code source de ses équipements dont celui du logiciel de pilotage automatique mis en cause dans un accident

[strato35]

Ça me fait un peu penser à l'expérience de pensée du bateau de Thésée ... version code source.

[xXxNeWgEnErAtIoN]

Ça c'est parce que la majorité des développeurs sont mauvais, un beau code n'a pas besoin d'être modifié et réarrangé.

Dans mon entreprise nous encadrons les codes les plus pourris du mois et nous les affichons dans l'open space où il y a les devs, avec le nom et prénom et la photo du dev.

Chaque mois nous regardons les commit et on fait le concours du code le plus degueulasse. On affiche bien les développeurs qui gagnent ce concours avec un petit rappel à l'ordre et on fournit une copie de la photo.

Au fil des ans le choix est beaucoup plus facile car on met au placard les développeurs qui codent comme des manches, la liste est vraiment petite, 2-3 devs par an.

[L33tige]

Ça c'est parce que la majorité des développeurs sont mauvais, un beau code n'a pas besoin d'être modifié et réarrangé.

Dans mon entreprise nous encadrons les codes les plus pourris du mois et nous les affichons dans l'open space où il y a les devs, avec le nom et prénom et la photo du dev.

Chaque mois nous regardons les commit et on fait le concours du code le plus degueulasse. On affiche bien les développeurs qui gagnent ce concours avec un petit rappel à l'ordre et on fournit une copie de la photo.

Au fil des ans le choix est beaucoup plus facile car on met au placard les développeurs qui codent comme des manches, la liste est vraiment petite, 2-3 devs par an.

Bon s'agirait d’arrêter de mentir. Parce-que personnellement si cela m'arrivait il y aurait des dents qui se mettraient à voler.

[strato35]

Ça c'est parce que la majorité des développeurs sont mauvais, un beau code n'a pas besoin d'être modifié et réarrangé.

Dans mon entreprise nous encadrons les codes les plus pourris du mois et nous les affichons dans l'open space où il y a les devs, avec le nom et prénom et la photo du dev.

Chaque mois nous regardons les commit et on fait le concours du code le plus degueulasse. On affiche bien les développeurs qui gagnent ce concours avec un petit rappel à l'ordre et on fournit une copie de la photo.

Au fil des ans le choix est beaucoup plus facile car on met au placard les développeurs qui codent comme des manches, la liste est vraiment petite, 2-3 devs par an.

Si un code a besoin d'être réécrit, ce n'est pas nécessaire qu'il soit mauvais.
Un projet durable, c'est un projet qui évolue, les besoins changent, donc le code aussi.

Un code dégeux ne devraient de toute façon ne pas passer la phase de review, donc théoriquement ce filtre doit permettre d'éviter à avoir à repasser sur quelque chose de sale.

[xXxNeWgEnErAtIoN]

Bon s'agirait d’arrêter de mentir. Parce-que personnellement si cela m'arrivait il y aurait des dents qui se mettraient à voler.

Pourquoi t'es pas photogénique ? On fournit des perruques pour les plus complexés, on n'est pas vache non plus hein.

[Edrixal]

Quel est votre avis sur le sujet ?
Partagez-vous l'opinion de Jones ? Pourquoi ?

De se que j'en comprend, toute modification même minime veut dire que le code source à été changer et donc on repart de zéro pour la durée d'existence du code.
Ca veut dire qu'une application qui évolue aura en effet sont code source qui va souvent changer. Y'a rien d’extraordinaire à ça...

De votre expérience, le code d'une application a-t-il une courte durée de vie ? Si oui, y a-t-il un risque pour les projets informatiques à l’avenir ?

Bha oui... Y'a qu'une application que je n'ai pas toucher depuis presque 2 ans, parce que le projet à été refait par une autre boite que celle ou je suis. L'appli bien qu'encore utilisée (puisque la boite en question n'a pas été capable de faire son travail et que du coup seul trois produit sur une vingtaine à été migré) n'évolue plus depuis 2 ans parce que stable et que les propriétaire de l'appli souhaite tout migré sur la nouvelle version.

Sinon sur la dizaines d'autre application que j'ai développer et que je maintient, y'a toujours des évolutions, parce que les besoins évolue, parce qu'à l'utilisation les utilisateurs ce rendent compte qu'ils pourrait gagner du temps en optimisant certaine chose ou en ajoutant des trucs auxquels ils n'avaient pas pensés initialement. Et là le code source bouge plus ou moins régulièrement.

Une appli de Gestion Électronique de Document n'a pas bouger pendant plus d'un ans avant de recevoir une demande pour modifier les critères de recherche parce qu'avec le nombre de document grandissant et le nombre d'appli différente qui y déverse des documents ils avaient besoin de plus de critère pour être efficace. Mais hormis ça, le code est stable, les seuls modif faite on été le paramétrage de nouveau type de document en base de donnée et le paramétrage des applications, là aussi en base de donnée.
A coter de ça, une application de gestion des sinistres évolue toute les semaines, entre les particularités des sinistres qu'il faut pouvoir prendre en charge, les modifications dans les formules de calculs (Bon ça je les ai mise en base, ça compte comme modification du code source ou non ?) les changements sur les éditions, les évolutions sur les demandes de statistique ect... Oui, ça bouge pas mal.

Après au lancement des projets via la phase de recette utilisateur y'a eux beaucoup de remonté de bug, mais depuis la mise en production, c'est vraiment anecdotique et les bugs remonté sont plus des particularités non prise en compte que de véritable bug. Par exemple un cas qui ne devais jamais arrivé qui n'a pas été pris en compte, n'a pas été vue en recette car normalement impossible, mais qui pour une raison inconnue arrive et provoque un bug sur le dossier en question.

Mais en soit tout ça c'est pas un mal, c'est parce que l'application vie et avance en fonction des besoins du client. Donc c'est logique et parfaitement normal que le code source change.

Après si j'ai mal compris et qu'on parle de refaire X fois la même chose de manière différente là j'y crois moyen, mais en admettant que ce soit vrais, les projets vont vite couler, parce que perte de temps > Perte d'argent > Fin du projet.

[L33tige]

Pourquoi t'es pas photogénique ? On fournit des perruques pour les plus complexés, on n'est pas vache non plus hein.

Parce-que c'est un comportement de gros frustré, c'est pas aux autres de payer le fait que t'es un déchet en fait.

[grunk]

Ça c'est parce que la majorité des développeurs sont mauvais, un beau code n'a pas besoin d'être modifié et réarrangé.

Dans mon entreprise nous encadrons les codes les plus pourris du mois et nous les affichons dans l'open space où il y a les devs, avec le nom et prénom et la photo du dev.

Chaque mois nous regardons les commit et on fait le concours du code le plus degueulasse. On affiche bien les développeurs qui gagnent ce concours avec un petit rappel à l'ordre et on fournit une copie de la photo.

Au fil des ans le choix est beaucoup plus facile car on met au placard les développeurs qui codent comme des manches, la liste est vraiment petite, 2-3 devs par an.

Serait surtout temps de mettre du code review en place. Si vous le faites pour afficher les mauvais , vous pouvez peut être le faire d'une manière plus positive (et préventive) pour les faire progresser. Mais c'est toujours plus facile de pointer du doigt plutôt que de tirer vers le haut

[pboulanger]

La longévité d'un code dépend de son usage.... En banque, on trouve des softs qui ont 20/30 ans de vie avec des codes qui ont été modifié, mis à jour des centaines de fois... Pareil pour des librairies de calculs comme celle pour la météo: on ne la réécrit pas tous les 5 matins! Le code jetable arrive avec la génération web où les techno changent 3 fois par an et qu'il faut tout réécrire pour être "à la mode".... D'ici à en faire une généralité il y a un gouffre...

[Anselme45]

La longévité d'un code dépend de son usage.... En banque, on trouve des softs qui ont 20/30 ans de vie avec des codes qui ont été modifié, mis à jour des centaines de fois... Pareil pour des librairies de calculs comme celle pour la météo: on ne la réécrit pas tous les 5 matins! Le code jetable arrive avec la génération web où les techno changent 3 fois par an et qu'il faut tout réécrire pour être "à la mode".... D'ici à en faire une généralité il y a un gouffre...

Non seulement la longévité d'un code dépend de son usage... mais la longévité d'un code ne dépend même pas de sa qualité!

J'ai plein d'exemples où des applications pourries font le "bonheur" de leur utilisateurs pendant de nombreuses années

[L33tige]

Non seulement la longévité d'un code dépend de son usage... mais la longévité d'un code ne dépend même pas de sa qualité!

J'ai plein d'exemples où des applications pourries font le "bonheur" de leur utilisateurs pendant de nombreuses années

Typiquement je suis tombé sur une méthode immonde qui était en fait un replaceAll mais qui datait du temps ou l'appli était en java 4, sauf qu'on est en 2020, donc bon le code est jamais immuable ça n'existe pas.

[grunk]

La longévité d'un code dépend de son usage.... En banque, on trouve des softs qui ont 20/30 ans de vie avec des codes qui ont été modifié, mis à jour des centaines de fois...

Avec toutes les problématiques que ça engendre. Y'a qu'à voir le niveau de service "online" des banques traditionnelles par rapport aux "neo banques". C'est juste honteux et surement en partie du aux infras qui tourne avec des trucs qui ont 30 ans et qui aujourd'hui sont difficile à faire évoluer. Et je suis pas certains que les néos banque prennent la sécurité plus à la légère que les autres.

Il y'a un juste millieu à trouver , savoir prendre le bon train en marche pour faire évoluer les infras sans pour autant succomber à la première mode venue.

[xXxNeWgEnErAtIoN]

Parce-que c'est un comportement de gros frustré, c'est pas aux autres de payer le fait que t'es un déchet en fait.

C'est pas moi qui code comme un malpropre, je n'ai rien à me reprocher contrairement à eux.

[Jamatronic]

C'est pas moi qui code comme un malpropre, je n'ai rien à me reprocher contrairement à eux.

1-- T'es un troll.
2-- T'es un âne.
3-- Ce n'est pas parce que tu ne comprends pas un code que le code est à jeter. Quand j'avais quinze ans j'écrivais du code que l'ingénieur en informatique moyen d'aujourd'hui ne comprendrait pas... donc je suppose que j'aurais eu le bonnet d'âne dans ta boîte de merde.

[Mat.M]

Ça me fait un peu penser à l'expérience de pensée du bateau de Thésée ... version code source.

merci pour le concept que je ne connaissais pas.

De toute façon parler d'identité d'un code me parait difficile ou alors il faut être minutieux et nommer les noms de fonction , de variable de manière très particulière.

[L33tige]

merci pour le concept que je ne connaissais pas.

De toute façon parler d'identité d'un code me parait difficile ou alors il faut être minutieux et nommer les noms de fonction , de variable de manière très particulière.

Ça marche aussi avec les taxis mexicains !

[PomFritz]

Ça c'est parce que la majorité des développeurs sont mauvais, un beau code n'a pas besoin d'être modifié et réarrangé.

Dans mon entreprise nous encadrons les codes les plus pourris du mois...

Je vois, ambiance inspecteur des travaux finis... Je crois surtout que la majorité des dév ont compris que se casser le cul ne rapportait pas plus et que seul le temps de réalisation compte. Tout le reste, c'est de l'art.

[StabiloHB]

Je crois surtout que la majorité des dév ont compris que se casser le cul ne rapportait pas plus et que seul le temps de réalisation compte. Tout le reste, c'est de l'art.

On peut ajouter les dead-line toujours plus proches, mais aussi que les clients veulent un truc fonctionnel peu importe comment et par qui c'est codé tant que ça fait ce qu'ils demandent dans le temps qu'ils demandent.

[rt15]

Derek Jones me paraît franchement à l'ouest. Il bosse dans quoi ?

Ici dans le milieu bancaire c'est la fête des dinosaures.
Les clients utilisent des versions du produits qui ne sont plus supportées depuis de nombreuses années.
Je sais pas s'ils payent tous des extensions de support, mais s'ils trouvent un bug, pas le choix, on fait la correction sur leur version antique, dans le code d'époque qui est donc modifié à la marge régulièrement.

Quand aux dernières version du produit, elles sont compilées avec un joyeux mélange de code du jour et de code qui date tout simplement de la création du repo de source.
Et le vieux code ne gère pas que des fonctionnalités qui ne sont plus utilisées. Au contraire, le vieux code est bien souvent le cœur du produit. Au lancement on essaie généralement de livrer un truc complet à 20% qui couvre 80% des cas. Puis on s’attelle à ajouter les 80% restant au fure et à mesure des volontés des clients.

Et encore je bosse sur logiciel "récent".
Je soupçonne que dans le bureau d'à côté 90% du code du produit (du vieux C et du Cobol) a été écrit par des gens qui sont à présent soit à la retraite, soit morts.
Cela n’empêche pas de rajouter une ligne ou deux par-ci par-là, de livrer le produit sous Docker ou de rajouter un connecteur, et de sortir une nouvelle version du logiciel.

Dire que l'on se fiche de la qualité du code car il n'y aura pas de maintenance est complètement irresponsable.
La mauvaise qualité du code fait explosé le budget de maintenance. Déjà car il a plus de chance de planter, ensuite parce que les corrections sont plus dures à réaliser.
Même pour les évolutions : rajouter un truc au sommet d'un château de carte ça se termine mal bien souvent.


Le code qui part à la corbeille, c'est soit un produit très jeune qui a été un échec, soit un produit très vieux dont plus personne ne connaît l'existence et le source "se perd", soit c'est une vielle branche de maintenance.

Pour qu'une branche de maintenance parte à la benne, faut que l'on soit sûr qu'il n'y a plus de client qui utilise la version donnée.
Autant dire que ça n'arrive jamais car à la R&D à part les ouvertures de bugs, on a aucun moyen de connaître la liste des clients et encore moins la version qu'ils utilisent...