Comment estimer la durée de vie d'une ligne de code?

J'essaie de trouver un moyen d'analyser la longévité du code dans les projets open source: c'est-à-dire pendant combien de temps une ligne de code spécifique est active et utilisée.

Ma pensée actuelle est que la durée de vie d'une ligne de code commence lors de sa première validation et se termine lorsque l'une des situations suivantes se produit:

• Il est modifié ou supprimé,
• Exclus des builds,
• Aucun code dans sa construction n'est maintenu pendant une certaine période de temps (disons, un an).

REMARQUE: Pour clarifier pourquoi une "modification" est comptée comme "mort", les lignes modifiées seront comptées comme une "nouvelle" génération ou ligne de code. De plus, à moins qu'il n'y ait un moyen facile de le faire, il ne serait pas tenu compte de la longévité d'une lignée ou de la descendance d'un ancêtre.

Quoi d'autre déterminerait la durée de vie d'une ligne de code?

Andy Ozment a regardé OpenBSD en 2006 avec le même genre de question: Lait ou vin: la sécurité des logiciels s'améliore- t-elle avec l'âge?

Vous pourrez peut-être apprendre de sa définition. C'est aussi un article très intéressant, avec une conclusion intéressante également, qui n'a pas été intégrée dans la tradition de la gestion de logiciels:

Sur une période de 7,5 ans et quinze versions, 62% des 140 vulnérabilités signalées dans OpenBSD étaient fondamentales : présentes dans le code au début de l'étude.

Il a fallu plus de deux ans et demi pour que la première moitié de ces vulnérabilités fondamentales soit signalée. Nous avons constaté que 61% du code source dans la version finale étudiée est fondamental: il reste inchangé par rapport à la version initiale publiée 7,5 ans plus tôt. Le taux de signalement des vulnérabilités fondamentales dans OpenBSD devrait donc continuer à influencer considérablement le taux global de signalement des vulnérabilités.

Nous avons également trouvé des preuves statistiquement significatives que le taux de rapports de vulnérabilité fondamentaux a diminué au cours de la période d'étude. Nous avons utilisé un modèle de croissance de la fiabilité pour estimer que 67,6% des vulnérabilités de la version de base avaient été trouvées. L'estimation du modèle du nombre attendu de vulnérabilités fondamentales signalées par jour est passée de 0,051 au début de l'étude à 0,024.

Je ne pense pas qu'il y ait de réponse à cela. Cela dépend fortement du projet. Certains sont plus stables au fil des ans, d'autres sont plus volatils / refactorisés / évolutifs au fil des ans.

De plus, c'est difficile à mesurer. Une ligne modifiée est-elle vraiment la fin de sa durée de vie? Qu'en est-il seulement d'un changement cosmétique comme le reformatage de la base de code avec des tabulations ou des espaces? À mon humble avis, cela ne compte pas comme une base de code renouvelée, mais ce serait selon vos critères.

Cela dit, je pense qu'une bonne partie des LOC vivent pour toujours.

La raison est simple: il est beaucoup plus facile d'ajouter du nouveau code plutôt que d'en supprimer. Surtout lorsque le système est complexe et s'est développé au fil des ans. Il arrive alors rapidement à un point où il est «risqué» de supprimer ou de modifier du code non trivial. Cela pourrait introduire des bugs, casser la compatibilité, introduire un effet papillon des changements ... Donc je pense que plus la base de code devient grande, plus elle est ancienne, plus les LOC vont rester.

De plus, seuls les bons programmeurs ont tendance à nettoyer les bases de code et à réduire les lignes. Tous les autres ont tendance à empiler les LOC. Et jusqu'à présent, ces derniers gagnent de loin. ;)

La suppression ou l'exclusion d'une ligne de code est définitivement une indication de la fin de sa durée de vie.

En reclassant l'édition, je poserais cette question: cette déclaration produit-elle un résultat différent après l'édition?

Si la réponse est oui, je dirais que la déclaration précédente n'est plus disponible, sinon je la considérerais toujours comme la continuation de la déclaration précédente.

Exemple de modification du résultat:

if ( a && b )

à:

if ( a || b )

Exemple de poursuite de la durée de vie:

foo.bar( baz );

à:

foo.prototype.bar.call( this, baz );