8

コード メトリクスに関する質問がいくつかあります。特に、目標値に関する質問があります。私が探しているのは、実際の制作プロジェクトで「通常の」ものです。多分それは私だけかもしれませんが、私がこれまでに取り組んだプロジェクトは、これらのことを念頭に置いていないので、ReSharper Code Issues または Visual Studio Code Metrics を実行すると、私が最初のプロジェクトのように思えます。そのため、値には常に驚かされます。

私の現在の SharePoint 割り当ての例:

Maintainability | Cyclomatic cmplx. | Inher. depth | Class coupl. | LOC
67              | 6,712             | 7            | 569          | 21,649
68              | 3,192             | 7            | 442          | 11,873

では、問題は、「実際に」どのような値を通常目にするかということです。最適な値とベスト プラクティスはさておき、通常はどのような値が使用されますか?

4

2 に答える 2

11

記載されているこれらの値は、アセンブリ レベルであると想定しています。そうであれば、Cyclomatic ComplexityとLines of Codeはメソッド レベルで最も役立ちます。継承の深さは、主にクラス レベルで検討する必要があります。クラス結合は、最初にメソッド レベルを調べてからクラス レベルを調べると、より有用なフィードバックを提供します。

あなたが含めたスタック オーバーフロー リンクで提供されているガイドラインに加えて、Code Complete 2nd Edition には、Cyclomatic Complexity メソッドについて次のように書かれています。

  • 0-5 ルーチンはおそらく問題ありません。
  • 6-10 ルーチンを簡素化する方法について考え始めます。
  • 10+ ルーチンの一部を 2 つ目のルーチンに分割し、最初のルーチンから呼び出します

「実際の」プロジェクトでは、使用している開発プロセスの種類によって、何が許容されるかが異なります。チームが TDD (テスト駆動開発) を実践していて、SOLIDコードを書こうと努力している場合、これらの指標は最適な値に近いはずです。

TAD (開発後のテスト)、または単体テストのないコードの場合は、すべてのメトリックが最適よりも高くなると予想されます。上昇した。それでも、目標は、コードがどのように開発されたかに関係なく、「悪い」メトリックを持つケースを制限することです。

于 2012-03-26T14:07:18.433 に答える
6

ソフトウェア メトリクスに関する根本的な誤解は、見栄えの良いレポートに入れると役立つというものです。

ほとんどの人は、次の欠陥のあるプロセスを使用しています。

  • ツールがサポートするあらゆる指標を収集する
  • レポートを編集する
  • 推奨値と比較する
  • 新たに発見された答えが対処する可能性のある質問を探し始めます

これは間違っており、逆行的であり、非常に多くのレベルで非生産的であり、面白くありません。メトリクスを収集するための適切なアプローチは、まず理由を理解することです。測る理由は何ですか？その答えがあれば、何を測定すべきかがわかるかもしれません。また、その理由と何を知っているかを考えると、さらなる調査に役立つ情報を取得する方法を理解することができます。

あなたがリストしたメトリクスには幅広い値を見てきましたが、正直に言うと、プロジェクトや環境全体での比較はあまり意味がありません.

同じチームが以前に作ったものに似たものを作ることはほぼ間違いありません。しかし、それを理解するためにメトリクスは必要ありません。

メトリクスを使用して調査する「ホットスポット」を見つけることができますが、品質に問題がある場合、いずれにせよバグは問題のあるモジュールに集まり、それらを探しに行くことはほとんど役に立ちません。

誤解しないでください。私はメトリクスが大好きです。私は複数のスクリプトとツールを作成して、視覚化を抽出し、それらを使用してあらゆる種類の派手なことを行いました。それはすべて楽しいものであり、有益でさえあったかもしれませんが、後者についてはあまり確信が持てません.

于 2012-03-27T12:18:35.840 に答える