経験的指標に基づいて、ソフトウェアが良いか悪いかをどのように知るのですか？

現在、5か月前にコア開発を終了したが、依然として高レベルの欠陥があるプロジェクトを検討するよう求められています。約10個の欠陥が修正されるごとに発生するのは、少なくとも4個、場合によっては8個の欠陥が発生することです。

ベンダーでのコーディング慣行は貧弱であり、これについては一般的な合意があると思います。しかし、ソフトウェアに構造的な問題があるかどうか疑問に思っていますか？欠陥密度は有用な尺度ですが、コアソフトウェアの作成が不適切な場合は、ベンダーが行っていることはすべて問題を解決することです。

インフラストラクチャでは、何かが不完全に構築されている場合、より明確に定義されていますが、LOCごとの欠陥のほかに、ソフトウェアにどのような測定値を使用できますか？

この製品は4か月間欠陥修正フェーズにありますが、重大な欠陥はまだ十分に解決されていません。回帰の問題を修正するだけで、新しい機能を注入することはありません。

これは開発品質の問題を示しており、満足していません。ただし、製品自体に根本的な欠陥がある場合、それは別の問題です。懸念されているのは、コアコードベースの作成が不十分であり、ドキュメントが限られているため、外部の開発者はすべて、問題をAからBにシフトしているだけです。機能的にします。

サードパーティから製品を受け入れ、サポートを求められた場合、標準を定義するためにどの受け入れ基準を使用しますか？

リード開発者にリリースごとのコードのピアレビューを行わせることに加えて、他に何ができるかわからない？

あなたはしません。

ソフトウェアの品質を客観的に測定することは非常に困難です。解決策がないほど難しい。この答えでは、解決策があるのか​​どうかという質問に手を出すことは控えていますが、解決策を定義するのが本当に難しいのはなぜかを指摘するだけです。

現状による推論

Kilian Fothが指摘したように、「良い」ソフトウェアのための簡単な手段があれば、私たち全員がそれを使用し、誰もがそれを要求するでしょう。

マネージャが特定のメトリックを実施することを決定したプロジェクトがあります。時にはそれが機能し、時には機能しなかった。重要な相関関係は認識していません。特に重要なシステムソフトウェア（飛行機、車など）には、SWの品質を「確保」するための多くのメトリック要件があります。これらの要件が実際に高品質をもたらすことを示す研究はありません。反対。

カウンターインテリジェンスによる推論

また、Kilianによって既に示唆されており、より一般的には、「メトリックはすべて再生可能であり、再生されます」と表現されています。

メトリックを再生するとはどういう意味ですか？開発者にとっては楽しいゲームです。メトリック値が本当に見栄えがよく、本当にくだらないことをしていることを確認できます。

LOCごとに欠陥を測定するとします。どうやってプレイするの？簡単-コードを追加するだけです！100行を超える操作を行わない愚かなコードを作成すると、突然LOCあたりの欠陥が少なくなります。何よりも、実際にソフトウェア品質をそのように低下​​させた。

ツールの欠点が悪用され、定義が最大限に拡張され、完全に新しい方法が発明されました。基本的に、開発者は本当に頭がいい人であり、あなたのチームにたった1人の開発者がいるのであれば、評価指標をプレイするのは楽しいでしょう。

これは、メトリックが常に悪いと言うことではありませんが、これらのメトリックに対するチームの態度は重要です。特に、これは、下請け業者とサードパーティベンダーの関係ではうまく機能しないことを意味します。

誤ったターゲティングによる推論

測定したいのはソフトウェアの品質です。測定するのは、1つ以上のメトリックです。

あなたが測定するものとそれがあなたに伝えると信じるものの間にはギャップがあります。このギャップは非常に大きなものです。

それは私たちの周りのあらゆる種類のビジネスで常に起こります。KPI（主要業績評価指標）に基づく決定を見たことがありますか？それはちょうど同じ問題です-あなたは会社がうまくやってほしいが、あなたは何か他のものを測定します。

定量化可能性による推論

メトリックを測定できます。これが私たちがそれらに対処する唯一の理由です。ただし、ソフトウェアの品質は、これらの測定可能なエンティティをはるかに超えており、定量化するのが非常に難しいことが多くあります。ソースコードはどの程度読みやすいのですか。デザインはどの程度拡張可能ですか？新しいチームメンバーが参加するのはどれくらい難しいですか？などなど

メトリックだけでソフトウェアの品質を判断し、定量化できない品質の部分に目をつぶると、確かにうまくいきません。

編集：

概要

上記はすべて、メトリックに基づいてソフトウェアが良いか悪いかを客観的に判断することについてです。つまり、メトリックを適用すべきかどうか、いつ適用すべきかについては何も言っていません。

実際、これは一方向の意味合いです。悪いメトリックは悪いコードを意味します。単方向とは、悪いコードが悪いメトリックを保証するものではなく、良いメトリックが良いコードを保証するものでもないことを意味します。一方、これ自体は、この意味を念頭に置いて、ソフトウェアを判断するためにメトリックを適用できることを意味します。

ソフトウェアAを測定すると、メトリックが非常に悪くなります。そうすれば、コードの品質が悪いことを確信できます。ソフトウェアBを測定し、メトリックが大丈夫な場合、コード品質についてはまったく手がかりがありません。「コードが良い=>メトリクスが良い」だけの場合でも、「メトリクスが良い=コードが良い」という考えにだまされないでください。

本質的に、メトリックを使用して品質の問題を検出できますが、品質自体は検出できません。

はい、ある程度のメトリックを調べることで、コードに品質の問題があることを確認できます。

具体的には、コードベースで複雑度分析ツールを実行すると、コードが良いか悪いかがわかります。

たとえば、ソースモニタを実行できます。

これにより、コードがどれほど複雑であるかがわかります。私が経験したすべての問題のあるシステムには、悪い数があったと言えます。許容範囲をはるかに超える10〜100のメソッドの複雑さ。ひどい数字。ひどい複雑さ、入れ子、深さなど。これは、多くの問題、一定の高い欠陥率、他の何かを壊さずに変更を加えるのが難しいなどにつながります。

もう一つは欠陥です。時間が経つにつれて、システムは安定するはずです。理想的には、新しい欠陥はゼロに向かう傾向があるか、または少ない数に平らになるはずです。つまり、新しい欠陥と現在の欠陥は時間とともに減少するはずです。

プロットは次のようになります。

経時的な欠陥

それらが一定のままであるか増加する場合、ソフトウェアは良くありません。あなたのたった4か月で、私はそれをさらに数か月から1年与えます。6か月から1年後、欠陥が絶え間なく発生していると、品質が低下します。あなたのチームは別の泥の玉を開発しました。

次のテスト。それらはありますか？そうでない場合は、品質が低下し、バグが増え、解約が増えます。それらがある場合、コードカバレッジなどのメトリックは、カバーされているコードの量を知るのに役立ちますが、品質を測定しません。すばらしいコードカバレッジの数値を見てきましたが、実際のテストはくだらないものでした。システムの動作や機能をテストしていませんでした。開発者は、管理のためのメトリック数を改善するためにそれらを書いていました。だから、あなたはテストをしなければならず、それらは良いものでなければなりません。 コードカバレッジメトリック自体は、品質の指標ではありません。

コードレビュー、それらを実行していますか？そうでない場合、品質が低下します。これは、ジュニア開発者にとって特に重要です。アジャイルを行う場合は、ストーリーに「コードレビュー」というコードレビュータスクを追加するだけです。管理者が数字を追跡したい場合は、Crucibleのようなレビューを追跡するツールが必要になります。ここでは、コードレビューの数値またはメトリックは、プロセスの一部であるという事実以外はそれほど重要ではないと思います。すべてのチェックインがレビューを必要とするわけではありません。しかし、レビューは、人々が車輪を再発明したり、他の人が理解および/または維持できないコードを書いたりしていないことを確認するのに役立ちます。

最後に、コードを評価する必要がありますが、そこにメトリックはありません。すべての問題のあるコードプロジェクトには、次の品質がありました。

• 不十分なデータ構造。すべてが文字列であるか、XMLがあらゆる場所で渡され、あらゆる場所で解析され、神のオブジェクト、または不必要に複雑なまたは汎用のデータ構造、ドメインモデルはありません。
• 組織や構造が不足しているため、重要なプロジェクトには、ロジックを分離する分割または階層化が必要です。 ここをご覧ください ...このタイプの組織または分離（あらゆる場所でのロジックの混合）が見られない場合、システムの保守と理解が難しくなります。
• 抽象化を超えて。時にはその逆が真であり、システムが過剰に抽象化されています。すべてがインターフェースと抽象クラスである場合、または大量のクラス「ラッパー」型クラスをナビゲートする必要がある場合、新しい開発者はオブジェクトの膨張をナビゲートできないため、品質が低下します。
• コードを理解するのは難しい。経験豊富な開発者で、理解しにくいコードを見ている場合、品質の問題が発生します。私の個人的な測定基準は、コードを見ていて、それを追うのが難しい、または愚かな気がする、またはロジックを理解するために多くの脳サイクルを浪費しているように感じる場合、それは悪いコードです。ベテランの開発者がフォローするのに苦労しているなら、新しい開発者にとってそれがどんなものになるか想像してみてください。問題が発生します。

私のアドバイスは、コードの複雑性分析を実行することです。結果を共有せずに、結果をフォローアップして、独立した調査（コードを参照）を行い、コードベースの全体的な健全性を判断します。これから、アクションプランを作成し、コードの複雑な領域の一部を修正してみてください。

メトリックの悲しいことは、メトリックの結果の値が改善される可能性がありますが、メトリックによって測定されることを意図した品質ではないことです...

Visual Studioには、コンパイラの警告をエラーとして扱うための設定があります。現在、一部の人々は警告を理解しておらず、コードをコンパイルするために、単純なトリックを使用します（「プラグマ無効警告」またはベースの非仮想メンバーを非表示にする「新しい」キーワードを関数/プロパティに追加するなど）クラス）。

ソースコードにアクセスできる場合は、静的コード分析を実行できます。.Netプロジェクトでは、FxCopやReSharper InspectCodeなどを使用できます。開発チームが正しく使用すると、ツールは品質の向上に役立ちます。しかし、もちろん、警告を理解せずに削除するための「修正」も可能です。

自動化されたテスト/ UnitTestsを見ることができます：コードカバレッジはどれくらい良いですか？ただし、カバレッジだけでは、テストが実際にコードをチェックするのか、それとも一度だけ実行したのかはわかりません。

高品質を目指して取り組む姿勢は、多くのツールとそのメトリックによってサポートされますが、開発者の態度のないメトリックは役に立ちません。

欠陥挿入のようなメトリックを収集することに加えて、注目すべき1つのことは、欠陥の原因を突き止めることです。多くの場合、それは仕様に関連しています。

基本的には、仕様の誤り、仕様の曖昧さ、インプラントが決定するために残されたもの、または実装のバグです。

より定性的なアプローチは、ソフトウェアが有用かどうかを尋ねることです。よく見ると、あらゆるソフトウェアの欠陥を見つけることができます。しかし、それがお金を稼ぐのに十分に機能するなら、それはそれほど悪くないかもしれません。

ボトム、知る方法はありません。

元の質問（哲学的回答の前）の場合：製品は何をすべきであり、それを行うのか？欠陥数/密度で測定するだけでは不十分です。これがライブラリであるか、アプリケーションであるか、コードベースの大きさ、問題の領域の大きさ、欠陥の重大度はわかりません。たとえば、123の入力形式のいずれかを処理しないことは、適切に処理されない形式の重要性に応じて、些細な欠陥またはショーストッパーになる可能性があります。そして、何よりも優れていることは高い水準です。

私はこの質問を前提にしています：コードとソフトウェアには違いがあります。 ソフトウェアは、クライアント/ユーザーが問題を解決するために使用するものとして定義しますが、コードはソフトウェアの構成要素です。

ソフトウェアは主観的にのみ測定できます。つまり、ソフトウェアにとって重要な測定基準は、人々がそれを使用して問題を解決するかどうかです。この測定基準は、他者の行動に依存するため、主観的です。注：一部の問題では、一部のソフトウェアが非常に有用であるため、高品質（計算用のExcel）であると考えられますが、別の問題（MP3ファイルの再生用のExcel）用の品質のソフトウェアではありません。

コードは（通常）経験的指標で測定できます。しかし、解釈は品質の「はい/いいえ」ではなく、実際には「0からN」のスケールでもありません。メトリックは標準に対して測定されます。したがって、メトリックは標準で定義された関心領域を見つけることができますが、関心領域がないことは、これが品質コードであることの証拠ではありません。たとえば、有用なメトリック：コンパイルされますか？いいえ->品質ではありません。はい-> ??? 単体テストに合格しましたか？番号？多分？（ユニットテストの品質コードですか？）、はい-> ???。

したがって、ゲーデルの不完全性証明が数学の公理に対して示したように（つまり、公理の有限セットに対して真または偽であると証明できない数学的ステートメントが存在します）、私たちは実際にこの品質に答えることができるとは思いませんコード？' すべてのコードに対して。直観的には、品質に答えるソフトウェアメトリックと、真か偽かを証明する数学の公理との間におそらくマッピングがあります。

この議論をする別の方法は、自然言語に踏み込むことです。ウィリアム・シェークスピア、ルイス・キャロル、マーク・トウェインはすべて成功した作家であり、その質の高さで多くの人に愛されています。しかし、ランダムな12年生よりも一貫して高い評価を与える、どのような標準の文法、語彙、スタイル、または音声を適用できますか？そして、これらの3つの合成尺度を作成することは可能かもしれませんが、ジョン・ブック（KJV）、JRRトールキン、ホーマー、セルバンテスなどをどのように評価しますか？その後、バローズ、フォークナー、ヘミングウェイ、シルビアプラスなどを投入します。メトリックは機能しません。

私は、彼らのプロセスを監査する（そして偏差を探す）ことでこれを測定します。

中央のソース管理、中央のビルドシステム、およびリリースされたブランチに統合する前にコードがテストされることを保証するプロセスを含むプロセスを提供するための証拠を探しています。

また、欠陥がリリースプロセスを通過した状況に応じて、プロセスがどのように変更されたかの証拠を探しています。

このレベルの監査に合格できない場合、一貫した信頼できるリリースを提供することを期待できません。

この監査に合格し、プロセスを継続的に改善している場合、出力の一貫性は時間とともに改善される可能性があります。

これで解決しない場合は、現在のコードベースの拡張とテストが問題になるコードアーキテクチャ上の問題がある可能性があり、その場合は適切なオプションはありません。

あなたが完全に自動化された測定を探しているなら、私はこれらの人をお勧めします：Software Improvement Group

これは基本的に、ソースコードから自動的に抽出できるさまざまなメトリックの集合体です（ユニットテストカバレッジ、関数サイズ、クラスエンタングルメント、複製、LOCなど）。これらの値は、1〜5つ星の評価に変換されます。

また、実際に読んでおく価値のあるすべてのメトリックを説明したまともな本「Building Maintainable software」もあります。