ソフトウェア品質の客観的指標[非公開]

ソフトウェア製品で測定できる品質には、目的への適合性（最終用途など）、保守性、効率など、さまざまな種類があります。これらのいくつかはやや主観的またはドメイン固有です（たとえば、優れたGUI設計原則は文化によって異なる場合や、使用状況に応じて、軍事的使用と消費者使用を考えます）。

私が興味を持っているのは、タイプのネットワーク（またはグラフ）に関連するより深い形式の品質とそれらの相互関係、つまり、各タイプが参照するタイプ、適切に関連する相互接続性の明確に識別可能なクラスターがあることです階層型アーキテクチャ、または逆に、型参照（「モノリシック」コード）の大きな「ボール」があります。また、各タイプおよび/またはメソッドのサイズ（たとえば、Javaバイトコードまたは.Net ILの量で測定）は、より複雑で管理しやすいものに分解される代わりに、大きな複雑なアルゴリズムがコードのモノリシックブロックとして実装されている場所を示す必要がありますチャンク。

このような考えに基づいた分析は、少なくとも品質の代用となる指標を計算できる可能性があります。高品質と低品質の間の正確なしきい値/決定点は主観的であると思われます。たとえば、保守性とは人間のプログラマーによる保守性を意味するため、機能の分解は人間の心の働きと互換性がなければなりません。そのため、考えられるすべてのシナリオで考えられるすべてのソフトウェアを超越する、数学的に純粋なソフトウェア品質の定義があるのではないかと思います。

また、品質の客観的なプロキシが普及すると、ビジネス上のプレッシャーにより、開発者は全体的な品質（プロキシで測定されない品質の側面）を犠牲にしてこれらのメトリックを追求することになるので、これは危険な考えかと思います。

品質に関する別の考え方は、エントロピーの観点からです。エントロピーは、システムが秩序状態から無秩序状態に戻る傾向です。中規模から大規模の実際のソフトウェアプロジェクトに携わったことのある人なら誰でも、コードベースの品質が時間とともに低下する傾向があることを理解するでしょう。一般に、ビジネス上のプレッシャーは、新しい機能に焦点を当てた変更（品質自体がアビオニクスソフトウェアなどの主なセールスポイントである場合を除く）、および回帰の問題と「適合」が合わない「シューホーン」機能性による品質の低下をもたらします品質とメンテナンスの観点。それでは、ソフトウェアのエントロピーを測定できますか？もしそうなら、どのように？

これは危険なアイデアです。品質の「客観的」プロキシは管理報酬に直接つながり、開発者は実際の品質を犠牲にしてこれらの指標を追求します。

これは意図しない結果の法則です。

品質は重要ですが、ソフトウェアの小さな側面の1つにすぎません。ソフトウェアによって作成される機能と価値は、品質よりもはるかに重要です。

すべてのメトリックは、メトリックを最適化するアクティビティにつながります。それは、あなたが本当に好きではないかもしれないという結果をもたらします。

ソフトウェアは非常に複雑です。それが本当に複雑であるかを理解することは困難です。

ユニットテストのコードカバレッジなどの「明白な」ものでさえ時間を浪費する可能性があります。100％に到達するには、テスト対象の単純なコードよりも実際には複雑なテストを作成する必要があります。100％の補償範囲に到達するには、許容できないコストがかかる場合があります。[ささいで小さな、めったに使用されないコードの代替手段は、検査によるテストです。しかし、それは100％のメトリクスゲームには合いません。]

別の例は、循環的複雑度です。これは、コード品質の最良の尺度の1つです。しかし、1つの大きな関数よりも読みにくい（そして維持するのが難しい）多くの小さな関数を作成することにより、ゲームを作成できます。コードレビューでは、読みにくいかもしれませんが、複雑さのしきい値を満たしていることに同意します。

また、品質の客観的なプロキシが普及すると、ビジネス上のプレッシャーにより、開発者は全体的な品質（プロキシで測定されない品質の側面）を犠牲にしてこれらのメトリックを追求することになるので、これは危険な考えかと思います。

ビンゴ、それについての「if」はありません。これは「測定障害」と呼ばれ、2002年にハーバード大学教授の本を参照してジョエルが何度も記事を書いたことが観察され、書かれています。

それは、そのようなメトリックが役に立たないという意味ではなく、インセンティブまたはポリシーをそのようなプロキシ測定に明示的に基づいてはならないということだけです。品質を改善したい場合は、非常に悪い値を持つプロキシメトリックを開始するのがよいでしょう。しかし、すべての指標に大きな価値があるからといって、品質が良いと結論付けることはできません。

私が興味を持っているのは、タイプのネットワーク（またはグラフ）に関連するより深い形式の品質とそれらの相互関係、つまり、各タイプが参照するタイプ、適切に関連する相互接続性の明確に識別可能なクラスターがあることです階層型アーキテクチャ、または逆に、型参照（「モノリシック」コード）の大きな「ボール」があります。

これはファンインとファンアウトのように聞こえます。ファンインは、特定のモジュールを呼び出すモジュールの数をカウントし、ファンアウトは、特定のモジュールによって呼び出されるモジュールの数をカウントします。使用すべき警告サインは、大規模なファンインと大規模なファンアウトを備えたモジュールです。これは、貧弱な設計とリファクタリングまたは再設計の重要なターゲットを示している可能性があるためです。

また、各タイプおよび/またはメソッドのサイズ（たとえば、Javaバイトコードまたは.Net ILの量で測定）は、より複雑で管理しやすいものに分解される代わりに、大きな複雑なアルゴリズムがコードのモノリシックブロックとして実装されている場所を示す必要がありますチャンク。

簡単な測定は、コード行です。プロジェクト全体のコードの合計行とモジュールごとのコード行に分割できます（おそらく、異なるサイズのモジュールを使用します）。これは、特定のモジュールを確認する必要があることを示す警告インジケーターとして使用できます。ソフトウェア品質の測定とメトリックに関する本では、欠陥率とモジュールサイズの関係が曲線的であり、KSLOCあたりの平均欠陥は175〜350 SLOCのサイズのモジュールに伴うことを示す作業について説明しています。

もう少し複雑なのは、システムのテスト容易性、理解可能性、および保守容易性を示すように設計された循環的複雑さです。循環的複雑度は、アプリケーションまたはモジュールを通る独立したパスの数をカウントします。テストの数、したがってテストの作成と実行に必要な労力は、循環的な複雑さに強く関係しています。

高品質と低品質の間の正確なしきい値/決定点は主観的であると思われます。たとえば、保守性とは人間のプログラマーによる保守性を意味するため、機能の分解は人間の心の働きと互換性がなければなりません。

それが本当かどうかはわかりません。

たとえば、人間の作業記憶には7個のプラス/マイナス2個のオブジェクトしか保持できないことを示唆する研究があります。これはおそらく、ファンインとファンアウトの測定に興味があります-モジュールで作業していて、それが〜7個を超える他のモジュールに接続されている場合、おそらくそれらを正確に追跡することはできません他のモジュールは私の頭の中にあります。

欠陥を循環的複雑度などのメトリックに関連付ける作業も行われています。システムの欠陥を最小限に抑えたいため、サイクロマティックの複雑さによって特定されるように、より多くの労力テストまたはリファクタリングが必要なポイントを特定できます。

また、品質の客観的なプロキシが普及すると、ビジネス上のプレッシャーにより、開発者は全体的な品質（プロキシで測定されない品質の側面）を犠牲にしてこれらのメトリックを追求することになるので、これは危険な考えかと思います。

これは、測定またはメトリックの場合です。システムを理解し、情報に基づいた意思決定を行うために使用する必要があります。「測定できないものを管理できない」というフレーズが思い浮かびます。高品質のソフトウェアが必要な場合は、その品質を評価するための測定とメトリックが必要です。ただし、これには裏返しがあります。数字だけで管理することはできません。情報に基づいた決定を下すために数字を使用できますが、数字がそう言うだけで決定を下すことはできません。

あなたが興味を持っている多くの資質のためのメトリックまたはプロキシがあります：

1. コードの行
2. ファンイン、ファンアウト
3. コード1000行あたりのエラー率
4. 循環的な複雑さ
5. コードカバレッジ
6. 決定点カバレッジ
7. メンテナンス活動によって修正/導入されたエラーの割合
8. 機能点分析

これらすべてのアイテムにはいくつかの問題があります。

1. メトリックを最適化するために行われている作業-普遍的な傾向。チームまたは個人の評価または報酬の基準としていずれかのメトリックが使用されると、大幅に悪化します。
2. コンテキストのないメトリックを認識していません。これは、ショップ間では比較が不可能であることを意味します-ショップ内でのみ、時間をかけて そのような比較から生じるメトリックは依然として価値があります-「1年前よりも今より正確にコードを生成していますか」。

これらの問題の総合的な効果は、TQM、品質保証（コントロールではない）、継続的改善、カイザンなど、より広い文化の中でのみこれらのようなメトリックが価値を持つ可能性が高いことです。両方の文化の要素を定義する必要があります、どのように変更する必要があるか。これらの定義がある場合、これらのようなメトリックは、コードの品質、作業慣行、生産性などの改善に役立つ不可欠なツールになります。このより広いコンテキストがないと、メトリックはメトリックを最適化する作業を生成します。生産性を高め、コストを削減するためのbeancounterのツールになります。そして、開発スタッフがゲームをプレイする際の障害になります。

メトリックに夢中になることもあれば、余裕のある最高の人材、ツール、エンジニアリングの実践、QAに夢中になることもあります。「Fooled by Randomness」を読んでいて、数字付きのきれいにフォーマットされた多数のレポートよりも自動化するのが好きな、いくつかの妄想的なQA天才がいると、私はずっと幸せになります。

メトリックにはこの根本的な問題があります。

提案されたメトリクスのほとんどすべてが、実際のコードの実際の世界で、生のSLOC（コードのソース行）と強くまたは非常に強く相関していることが示されています。

これが、1970年代にHalsteadのメトリクスを殺したものです。（ある偶然、1978年頃、私はHalsteadの測定基準についての新しいPhDによる講演に参加し、彼はこれを指摘しました。）

最近では、McCabeの循環的複雑度が生のSLOCと非常に強く相関していることが示されており、McCabeのメトリックが有用な何かを教えてくれた場合、研究を行った男は大声で疑問を呈しました。

何十年もの間、大きなプログラムは小さなプログラムよりも問題がある可能性が高いことを知っています。私たちは何十年もの間、大きなサブルーチンは小さなものよりもバグがある可能性が高いことを知っています。これを伝えるために不可解なメトリックが必要なのはなぜですか。テーブルに散らばる4つのプリンタページを見るだけで十分に納得できるはずです。

ここで他のすべての答えを考えると、私はこの小さなものでちょっとばかげていると感じます。Crap4jを見てください。Crap4jは、Javaのメソッドを悪臭の程度によってランク付けしようとします。（プロジェクトは放棄されたように見えます。）

循環的な複雑さとテスト範囲の組み合わせを使用します。他のすべてのメトリックと同様に、それはゲーム可能です。