コードの安定性を測定するためのソースコードメトリック？

リリースサイクル（実装、テスト、バグ修正、リリース）でソフトウェアがどのように開発されるかを考えると、コードベースで変更されるコードの行に何らかのパターンが見えるはずだと考えていました。たとえば、プロジェクトの終わりに向かって、コードがより安定した場合、単位時間あたりに変更されるコードの行が少なくなることがわかります。

たとえば、プロジェクトの最初の6か月の平均は1日あたり200行のコードでしたが、先月は1日あたり50行のコードであり、先週（製品DVDの直前）出荷された）、コードの行はまったく変更されていません（コードのフリーズ）。これは単なる例であり、特定のチームが採用した開発プロセスに応じてさまざまなパターンが出現する可能性があります。

とにかく、単位時間あたりのコードの修正行数を使用してコードベースの安定性を測定するコードメトリック（それらに関する文献はありますか）はありますか？プロジェクトがどこかで手に入れようとしている場合や、リリースの準備がまだ整っていない場合に、感覚をつかむのに役立ちますか？バージョン管理システムからこの情報を抽出し、統計を生成できるツールはありますか？

マイケル・フェザーズが説明した1つの尺度は、「アクティブなクラスのセット」です。

彼は追加されたクラスの数をそれらの「クローズ」に対して測定します。クラスクロージャを次のように説明します。

クラスは、その日付から現在までの間にそれ以上の変更が発生しない日付で閉じられます。

彼はこれらのメジャーを使用して、次のようなチャートを作成します。

2本の線の間隔が小さいほど良い。

コードベースに同様の尺度を適用できる場合があります。クラスの数は、コードの行数と相関している可能性があります。これを拡張して、クラスメジャーごとにコード行を組み込むこともできます。大きなモノリシッククラスがある場合は、グラフの形状が変わる可能性があります。

機能のクラスへの比較的一貫したマッピングがある場合、またはファイルシステムに関しては、バージョン管理システムにgourceのようなものをフックし、開発の大部分が焦点を当てている場所を非常に迅速に把握できます（それによりコードのどの部分が最も不安定です）。

これは、比較的きちんとしたコードベースがあることを前提としています。コードベースが泥だらけの場合、本質的に相互依存関係のために作業中の小さな部分がすべて表示されます。そうは言っても、それ自体（機能の作業中のクラスタリング）がコードベースの品質をよく示している可能性があります。

また、ビジネスチームと開発チーム全体が、開発中の機能を分離する何らかの方法を持っていることを前提としています（バージョン管理の分岐、一度に1つの機能など）。たとえば、同じブランチで3つの主要な機能を使用している場合、コードの安定性よりも大きな問題があるため、この方法では意味のない結果が生成されます。

残念ながら、私は自分の主張を証明するための文献を持っていません。それは、良い（そしてあまり良くない）コードベースでgourceを使用した私の経験にのみ基づいています。

gitまたはsvnを使用していて、バージョンが0.39以上の場合、プロジェクトフォルダーでgourceを実行するのと同じくらい簡単です。

変更された行の頻度をコードの安定性の指標として使用することには、少なくとも疑問があります。

最初に、変更されたラインの経時的な分布は、プロジェクトのソフトウェア管理モデルに大きく依存します。さまざまな管理モデルには大きな違いがあります。

第二に、この仮定の犠牲者は明確ではありません-ソフトウェアの安定性によって引き起こされた変更された行の数が少ないか、単に期限が切れて開発者が現在いくつかの変更を行わず、リリース？

3番目に、新しい機能が導入されると、ほとんどの行が変更されます。しかし、この新機能はコードを安定させません。開発者のスキルと設計の品質に依存します。一方、深刻なバグでさえ、ほとんど行を変更せずに修正される可能性があります-この場合、ソフトウェアの安定性は大幅に向上しますが、変更された行数はそれほど大きくありません。

ロバストネスとは、命令セットの正しい機能に関連する用語であり、それらの命令を表現するために使用されるテキストの量、冗長性、簡潔さ、文法の正確さではありません。

確かに構文は重要であり、正しい必要がありますが、それを超えるものは、指示の「メトリック」を見て指示の目的の機能に関係しているため、あなたはティーカップ。

堅牢性はテストによって測定されます。単体テスト、煙テスト、自動回帰テスト。テスト、テスト、テスト！

あなたの質問に対する私の答えは、あなたが堅牢性の答えを求める際に間違ったアプローチを使用しているということです。コードの行は、コードを占める行以外のものを意味するのは赤いニシンです。コードは、必要なことを実行していることをテストする場合に、コードが実行したいことを実行するかどうかを知ることができます。

適切なテストハーネスを再確認し、コードメトリックの神秘主義を避けてください。

ご多幸を祈る。