コード行の寿命をどのように推定できますか？

私は、オープンソースプロジェクトのコードの寿命を分析する方法、つまり特定のコード行がアクティブで使用中の期間を把握しようとしています。

私の現在の考え方は、コードの寿命は最初にコミットされたときに始まり、次のいずれかが発生したときに終わるというものです。

• 編集または削除され、
• ビルドから除外、
• ビルド内のコードは、一定期間（1年など）維持されません。

注：「編集」が「死」としてカウントされる理由の明確化として、編集された行は「新しい」世代、またはコード行としてカウントされます。また、これを行う簡単な方法がない限り、系統の寿命、または先祖からの降下の説明はありません。

コードの寿命を決定するものは他にありますか？

Andy Ozmentは2006年にOpenBSDを見て、同じような質問をしました：Milk or Wine：ソフトウェアセキュリティは年齢とともに向上しますか？

あなたは彼の定義から学ぶことができるかもしれません。また、非常に興味深い論文であり、興味深い結論もあります。ソフトウェア管理の伝承には組み込まれていません。

7.5年と15回のリリースの期間にわたって、OpenBSDで報告された140の脆弱性の62％が根本的なものであり、調査開始時にコードに存在していました。

これらの基本的な脆弱性の前半が報告されるまでに2年半以上かかりました。調査した最終バージョンのソースコードの61％が基本であることがわかりました。7.5年前にリリースされた初期バージョンから変更されていません。したがって、OpenBSDの基本的な脆弱性の報告率は、脆弱性報告の全体的な率に大きく影響し続ける可能性があります。

また、調査期間中に基本的な脆弱性レポートの割合が減少したという統計的に有意な証拠も見つかりました。信頼性成長モデルを使用して、基礎バージョンの脆弱性の67.6％が見つかったと推定しました。1日に報告される基礎的な脆弱性の予想数に関するモデルの推定値は、研究開始時の0.051から0.024に減少しました。

その答えはないと思います。プロジェクトに大きく依存しています。長年にわたってより安定しているものもあれば、長年にわたってより不安定/リファクタリング/進化しているものもあります。

さらに、測定することは困難です。編集された行は本当に寿命の終わりですか？タブやスペースを使用してコードベースを再フォーマットするような外観上の変更だけはどうですか？私見は、更新されたコードベースとしてカウントされませんが、それはあなたの基準に従っています。

とはいえ、LOCのかなりの部分は永遠に生きていると思います。

その理由は簡単です。新しいコードを削除するよりも、新しいコードを追加する方が簡単です。特に、システムが複雑で、長年にわたって成長している場合。その後、すぐに重要なコードを削除または変更することが「危険」になります。バグが発生したり、互換性が壊れたり、変更のバタフライ効果が発生したりする可能性があります。したがって、コードベースが大きくなればなるほど、古いものほどLOCが残ります。

さらに、優秀なプログラマーだけがコードベースをクリーンアップし、行を減らす傾向があります。他のすべてはLOCを積み上げる傾向があります。そしてこれまでのところ、後者が圧倒的に勝っています。;）

コード行を確実に削除または除外することは、その寿命の終わりを示しています。

編集をグレードアップして、この質問をします。このステートメントは、編集後に異なる結果を生成しますか？

答えが「はい」の場合、前のステートメントは使用できなくなっていると思いますが、そうでない場合は、前のステートメントの継続と見なします。

結果を変更する例：

if ( a && b )

に：

if ( a || b )

寿命を継続する例：

foo.bar( baz );

に：

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