コードメトリクスの魅力は何ですか？[閉まっている]

最近、SOに関する「コードメトリクス」関連の質問をいくつか見てきましたが、その魅力は何でしょうか。最近の例を次に示します。

• 提供されたコードがくだらないことをあなたに納得させるコードメトリクス
• コードの行数が有用なメトリックである場合
• 品質テストを書く

私の考えでは、コードレビューの代わりにメトリックを使用することはできません。

• 一部の指標は、レビューが必要な場所を示している場合があります。
• 短期間のメトリックの急激な変化は、レビューが必要な場所を示している可能性があります

しかし、それ自体が常に「良い」または「悪い」コードを示す単一のメトリックを考えることはできません-測定値が見ることができないものには常に例外と理由があります。

私が見落としていたコードメトリクスから得られる魔法の洞察はありますか？怠惰なプログラマー/マネージャーは、コードを読まない言い訳を探していますか？人々は巨大なレガシーコードベースを提示され、開始する場所を探していますか？どうしたの？

注：私は回答とコメントの両方で特定のスレッドでこれらの質問のいくつかを尋ねましたが、返信がありませんでした。おそらく何かが足りないので、コミュニティ一般に尋ねるべきだと思いました。メトリックバッチジョブを実行し、実際に他の人のコード（または自分のコード）を再度読み取る必要がないのは素晴らしいことです。実用的ではないと思います。

編集：私は議論されているすべてではないにしてもほとんどの測定基準に精通しており、それらの要点を単独で、または任意の品質基準として見ていません。

このスレッドの答えは、彼らが話しているようにちょっと奇妙です：

• これらの指標の「唯一の受益者」のような「チーム」。
• 「メトリクス」は、それ自体が何かを意味するように。

1 /メトリクスは1つの母集団ではなく、3つの母集団用です。

• 開発者：コードの静的分析に関する瞬間的 な静的コードメトリック（循環的複雑度、コメントの品質、行数など）に関心があります。
• プロジェクトリーダー：ユニットテスト、コードカバレッジ、継続的インテグレーションテストから得られる毎日の ライブコードメトリックに関心があります
• ビジネススポンサー（彼らは常に忘れられていますが、彼らは利害関係者であり、開発にお金を払っています）：彼らはアーキテクチャ設計、セキュリティ、依存関係などに関する毎週の グローバルコードメトリクスに関心があります...

もちろん、これらすべての指標は3つの母集団すべてで監視および分析できますが、それぞれの種類は、特定の各グループでより適切に使用できるように設計されています。

2 /メトリックは、それ自体でコードのスナップショットを表します。つまり、何も意味しません。

「良い」または「悪い」コードを示す可能性があるのは、これらのメトリックの組み合わせ、およびこれらのさまざまなレベルの分析の組み合わせですが、さらに重要なのは、これらのメトリックの傾向です。

これは、ビジネスマネージャー/プロジェクトリーダー/開発者がさまざまな可能なコード修正の中で優先順位を付けるのに役立つため、実際の付加価値をもたらすこれらのメトリックの繰り返しです。

言い換えれば、「メトリックの魅力」についてのあなたの質問は、以下の違いを参照している可能性があります。

• 「美しい」コード（それは常にビホルダーコーダーの目にありますが）
• 「良い」コード（これは機能し、機能することを証明できます）

したがって、たとえば、循環的複雑度が9の関数は、循環的複雑度が42の1つの長く複雑な関数とは対照的に、「美しい」と定義できます。

ただし、次の場合：

• 後者の関数は、95％のコードカバレッジと組み合わされて、着実に複雑になっています。
• 一方、前者は複雑さが増しており、カバレッジは... 0％です。

議論することができます：

• 後者は「良い」コードを表します（動作し、安定しており、変更する必要がある場合は、変更後も動作するかどうかを確認できます）、
• 前者は「悪い」コードです（必要なすべてをカバーするためにいくつかのケースと条件を追加する必要があり、回帰テストを行う簡単な方法はありません）

したがって、要約すると：

それ自体が常に示す単一のメトリック[...]

：コードがより「美しい」可能性があることを除いて、それほど多くはありません。それ自体はそれほど意味がありません。

私が見落としていたコードメトリクスから得られる魔法の洞察はありますか？

メトリックの組み合わせと傾向だけが、あなたが求めている本当の「魔法の洞察」を与えます。

数か月前に、循環的複雑度を測定する1人の仕事として行ったプロジェクトがありました。これが、この種の指標に初めて触れたときです。

私が最初に得た報告は衝撃的でした。（imho）非常に単純な関数でさえ、ほとんどすべての関数がテストに失敗しました。論理サブタスクが一度だけ呼び出された場合でも、サブルーチンに移動することで、複雑さを回避しました。

ルーチンの残りの半分については、プログラマーとしての私のプライドが始まり、同じように、よりシンプルで読みやすいように書き直そうとしました。それはうまくいき、私は顧客のyclomaticの複雑さのしきい値に最も達することができました。

結局、私はほとんどの場合、より良いソリューションとはるかにクリーンなコードを思いつくことができました。パフォーマンスはこれに悩まされませんでした（私を信じてください-私はこれについて妄想的です、そして私はコンパイラ出力の逆アセンブルをかなり頻繁にチェックします）。

コードを改善する理由/動機としてメトリックを使用する場合、メトリックは良いことだと思います。ただし、いつ停止してメトリック違反の許可を求めるかを知ることは不滅です。

メトリックはガイドおよびヘルプであり、それ自体で終了するものではありません。

私が今まで使用した中で最高のメトリックは、CRAPスコアです。

基本的に、これは加重循環的複雑度を自動テストカバレッジと比較するアルゴリズムです。アルゴリズムは次のようになります。CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) ここで、comp（m）はメソッドmの循環的複雑度であり、cov（m）は自動テストによって提供されるテストコードカバレッジです。

前述の記事の作成者（読んでください...時間をかけるだけの価値があります）は、最大CRAPスコア30を提案しています。これは、次のように分類されます。

Method’s Cyclomatic Complexity        % of coverage required to be
                                      below CRAPpy threshold
------------------------------        --------------------------------
0 – 5                                   0%
10                                     42%
15                                     57%
20                                     71%
25                                     80%
30                                    100%
31+                                   No amount of testing will keep methods
                                      this complex out of CRAP territory.

すぐにわかるように、メトリックは、複雑ではなく、優れたテストカバレッジと組み合わされたコードを書くことで報われます（ユニットテストを書いている場合、カバレッジを測定する必要があり、測定していない場合は...まあ、風に唾を吐くのを楽しむでしょう同様に）。;-)

ほとんどの開発チームでは、CRAPスコアを8未満にするために一生懸命努力しましたが、十分なテストで複雑さをカバーしている限り、許容できる追加の複雑さを正当化する正当な理由がある場合。（複雑なコードを書くことは常にテストするのが非常に困難です...このメトリックの隠れた利点のようなものです）。

ほとんどの人は、CRAPスコアに合格するコードを最初に書くのは難しいと感じました。しかし、時間の経過とともに、彼らはより良いコード、問題の少ないコード、そしてデバッグがはるかに簡単なコードを作成しました。どの指標の中でも、これは懸念が最も少なく、利益が最も大きい指標です。

私にとって、悪いコードを特定する最も重要な指標は循環的複雑度です。私のプロジェクトのほとんどすべてのメソッドはCC10未満であり、バグは常にCCが30を超えるレガシーメソッドで見つかります。通常、CCが高い場合は次のことを示します。

• 急いで書かれたコード（つまり、問題が複雑な解決策を必要としたためではなく、エレガントな解決策を見つける時間がありませんでした）
• テストされていないコード（誰もそのような獣のテストを書きません）
• 何度もパッチを当てて修正したコード（つまり、ifsとtodoコメントでいっぱい）
• リファクタリングの主なターゲット

優れたコードレビューは、優れた静的分析ツールに代わるものではありません。もちろん、優れた単体テストのセットに代わるものではありません。現在、単体テストは、一連の受け入れテストなしでは優れていません。

コードメトリクスは、ツールボックスに入れる別のツールであり、それ自体がソリューションではなく、必要に応じて使用するためのツールにすぎません（もちろん、ボックス内の他のすべてのツールを使用してください）。

人々は、コードを理解して説明するための機械的な方法のアイデアに惹かれます。もしそうなら、効率と生産性への影響を考えてください！

「コードの良さ」の指標は「良い散文」の指標とほぼ同じくらい賢明であることに同意します。ただし、それはメトリックが役に立たないという意味ではなく、おそらく誤用されているだけです。

たとえば、一部のメトリックの極値は、考えられる問題への道を示しています。1000行の長さの方法はおそらく保守不可能です。単体テストコードカバレッジがゼロのコードには、多くのテストを含む同様のコードよりも多くのバグが含まれている可能性があります。サードパーティのライブラリではないリリースの直前にプロジェクトに追加されたコードの大幅な増加は、おそらく特別な注意の原因になります。

メトリックを提案として使用する場合（危険信号）、おそらくそれらは役立つ可能性があると思います。問題は、人々がSLOCの生産性またはテストのあるラインのパーセンテージで品質を測定し始めるときです。

私の非常に主観的な意見は、コードメトリクスは本質的に定量化できないものを定量化できるという魅力的な制度的魅力を表現しているということです。

ある意味で、少なくとも心理的には理にかなっています-評価または理解できないことについて、どのように決定を下すことができますか？もちろん、最終的には、主題に精通している（そして少なくとも評価しようとしているものと同じくらい優れている）か、知識のある人に尋ねない限り、品質を評価することはできません。もちろん、問題を元に戻すだけです。一歩。

その意味で、SATスコアで大学入学者を評価するのは、おそらく合理的な例えでしょう。それは不公平であり、あらゆる種類の微妙な点を見逃していますが、定量化する必要がある場合は、何かをしなければなりません。

それが良い手段だとは言わないが、それの制度的な魅力を見ることができるということだけだ。そして、あなたが指摘したように、おそらくいくつかの合理的なメトリックがあります（500以上のラインメソッドがたくさんあり、複雑さが高い-おそらく悪い）。私はこれを買った場所に行ったことがありませんが。

私が信じているコードメトリックが1つあります。

私は大きなシステムに取り組んでいます。新しい要件が1つ出てきたら、それをコーディングすることにしました。完了してバグが解決したら、バージョン管理システムにチェックインします。そのシステムは差分を取り、私が行ったすべての変更をカウントします。

その数が少ないほど良いです。

メトリックと自動テストは、完全なコードレビューに代わるものではありません。

彼らはただ物事をスピードアップします。自動チェッカーを使用すると、従うのを忘れた規則や、指定されたパッケージやメソッドを使用していることなどを簡単に確認できます。他の人の時間を使わずに修正できることを確認できます。

マネージャーはまた、生産性について正確な数値が得られていると感じており（実際にはそうではない場合が多いですが）、人々をよりうまくやりくりできるはずなので、メトリックスも気に入っています。

測定は、次の場合にのみ役立ちます。

• チームはそれらを開発しました
• チームは彼らに同意しました
• それらは特定の領域を識別するために使用されています

一般に、それに適合しないメトリックは、チームがそれに最適化することで苦しみます。コードの行を測定したいですか？おやおや、彼らがいくつ書くことができるか見てください！あなたはコードカバレッジを測定したいのですが、私がそのコードをカバーするのを見てください！

メトリックは傾向を特定するのに役立つと思います。実際、ビルドが中断したときのプロット、コードチャーン（プロジェクト全体で変化するコードの行数）など、いくつかの有用なメトリックを見てきました。しかし、チームがそれらを考え出していない場合、または彼らがそれらに同意または理解していない場合、あなたはおそらく傷ついた世界にいます。

これがstan4jの複雑さのメトリクスです。

日食クラス構造分析ツール。

私はこのツールとメトリクスが好きです。私はメトリックを統計、インジケーター、警告メッセージとして扱います。一部のメソッドまたは一部のクラスが実際に複雑なロジックを持っているために、それらを監視し、リファクタリングする必要があるかどうかを確認するか、注意深く確認する必要があります。それらはエラーが発生しやすいです。また、複雑なものから単純なものまで学ぶのが好きなので、ソースコードを学ぶための分析ツールとしても使用しています。実際には、Robert C. Martin Metrics、Chidamber＆Kemerer Metrics、Count Metricsなどの他の指標が含まれていますが、これが一番好きです。

複雑さのメトリクス

循環的複雑度のメトリクス

循環的複雑度（CC） メソッドの循環的複雑度は、メソッドの制御フローグラフ内の決定ポイントの数を1つ増やしたものです。決定ポイントは、if / for / whileステートメント、case / catch句、および同様のソースコード要素で発生します。これらの要素では、制御フローが線形ではありません。単一の（ソースコード）ステートメントによって導入される（バイトコード）決定ポイントの数は、ブール式の複雑さなどに応じて異なる場合があります。メソッドの循環的複雑度の値が高いほど、メソッドの制御フローグラフのすべてのブランチをテストするために必要なテストケースが多くなります。

平均循環的複雑度 アプリケーション、ライブラリ、パッケージツリー、またはパッケージのすべてのメソッドにわたる循環的複雑度メトリックの平均値。

ファットメトリック アーティファクトのファットメトリックは、アーティファクトの適切な依存関係グラフのエッジの数です。依存関係グラフのタイプは、メトリックバリアントと選択したアーティファクトによって異なります。

Fat アプリケーション、ライブラリ、またはパッケージツリーのFatメトリックは、そのサブツリー依存関係グラフのエッジカウントです。このグラフには、パッケージツリー階層内のすべてのアーティファクトの子が含まれているため、リーフパッケージも含まれています。（コンポジションビューで適切なグラフを表示するには、構造エクスプローラーのフラットパッケージトグルを無効にする必要があります。選択したアーティファクトがライブラリの場合は[ライブラリの表示]トグルを有効にする必要があります。それ以外の場合は無効にする必要があります。）

パッケージのFatメトリックは、そのユニット依存関係グラフのエッジカウントです。このグラフには、パッケージのすべてのトップレベルクラスが含まれています。

クラスのFatメトリックは、そのメンバーグラフのエッジカウントです。このグラフには、クラスのすべてのフィールド、メソッド、およびメンバークラスが含まれています。（このグラフとFat値は、コード分析がクラスではなく詳細レベルのメンバーで実行された場合にのみ使用できます。）

ライブラリ依存関係のファット（Fat-ライブラリ） アプリケーションのライブラリ依存関係のファットメトリックは、ライブラリ依存関係グラフのエッジカウントです。このグラフには、アプリケーションのすべてのライブラリが含まれています。（コンポジションビューで適切なグラフを表示するには、構造エクスプローラーの[ライブラリの表示]トグルを有効にする必要があります。）

フラットパッケージ依存関係のファット（Fat-パッケージ） アプリケーションのフラットパッケージ依存関係のファットメトリックは、フラットパッケージ依存関係グラフのエッジカウントです。このグラフには、アプリケーションのすべてのパッケージが含まれています。（コンポジションビューで適切なグラフを表示するには、構造エクスプローラーのフラットパッケージトグルを有効にし、ライブラリの表示トグルを無効にする必要があります。）

ライブラリのFatfor Flat Package Dependenciesメトリックは、フラットパッケージ依存関係グラフのエッジカウントです。このグラフには、ライブラリのすべてのパッケージが含まれています。（コンポジションビューで適切なグラフを表示するには、構造エクスプローラーのフラットパッケージとライブラリの表示の切り替えを有効にする必要があります。）

トップレベルクラスの依存関係のファット（Fat-ユニット） アプリケーションまたはライブラリのトップレベルクラスの依存関係のファットメトリックは、そのユニット依存関係グラフのエッジカウントです。このグラフには、アプリケーションまたはライブラリのすべての最上位クラスが含まれています。（妥当なアプリケーションの場合、大きすぎて視覚化できないため、コンポジションビューに表示できません。ユニット依存関係グラフはパッケージに対してのみ表示できます。）

メトリックは、プロジェクトの改善または低下を判断するのに役立つ場合があり、スタイルや規則の違反を確実に見つけることができますが、ピアコードレビューを行うことに代わるものはありません。それらがないと、コードの品質を知ることはできません。

ああ...そしてこれはあなたのコードレビューの参加者の少なくとも1人が手がかりを持っていることを前提としています。

コードメトリクスはコードレビューの代わりにはならないということに同意しますが、コードレビューを補完する必要があると思います。「測定できないものは改善できない」ということわざに戻ったと思います。コードメトリクスは、開発チームに定量化可能な「コードの臭い」またはさらなる調査が必要なパターンを提供できます。ほとんどの静的分析ツールで取得されるメトリックは、通常、この分野の短い歴史の中で研究の過程で重要な意味を持つことが特定されたメトリックです。

メトリックはコードレビューの代わりにはなりませんが、はるかに安価です。それらは何よりも指標です。

答えの一部は、いくつかのコードメトリクスが質問への答えを非常に迅速に最初に突き刺すことができるということです：このコードはどのようなものですか？

「コード行」でさえ、見ているコードベースのサイズを知ることができます。

別の回答で述べたように、メトリックの傾向から最も多くの情報が得られます。

それ自体のメトリックは特に興味深いものではありません。重要なのは、それらを使って行うことです。

たとえば、コードの1行あたりのコメント数を測定している場合、適切な値は何だと思いますか？知るか？あるいはもっと重要なことは、誰もが自分の意見を持っているということです。

ここで、コードの1行あたりのコメント数を、バグの解決にかかる時間またはコーディングに起因するバグの数と関連付けることができる十分な情報を収集すると、経験的に有用な数を見つけ始めることができます。 。

ソフトウェアでメトリックを使用することと、他のプロセスで他のパフォーマンス測定値を使用することの間に違いはありません。最初に測定し、次に分析し、次にプロセスを改善します。あなたがしているのが測定だけであるなら、あなたはあなたの時間を無駄にしている。

編集：スティーブンA.ロウのコメントに応えて-それは絶対に正しいです。どのデータ分析でも、因果関係と単なる相関関係を区別するように注意する必要があります。また、適合性に基づいてメトリックを選択することが重要です。コーヒーの消費量を測定し、コードの品質を評価しようとしても意味がありません（ただし、試した人もいると思います;-)）

しかし、関係（因果関係があるかどうか）を見つける前に、データが必要です。

収集するデータの選択は、検証または改善するプロセスに基づいています。たとえば、コードレビュー手順の成功を分析しようとしている場合（「成功」の独自の定義を使用して、バグの削減またはコーディングバグの削減、またはターンアラウンドタイムの​​短縮など）、測定するメトリックを選択しますレビューされたコードのバグの合計率とバグの率。

したがって、データを収集する前に、データをどのように処理するかを知っておく必要があります。メトリクスが手段である場合、終わりは何ですか？

メトリックの小さな変更に意味があるとは思いません。複雑度20の関数は、複雑度30の関数よりも必ずしもクリーンであるとは限りません。ただし、メトリックを実行して大きな違いを探すことは価値があります。

あるとき、私は数十のプロジェクトを調査していましたが、プロジェクトの1つは最大複雑度の値が約6,000でしたが、他のすべてのプロジェクトの値は約100以下でした。それは野球のバットのように頭を打った。明らかに、そのプロジェクトでは何か変わった、おそらく悪いことが起こっていました。

私たちはプログラマーです。私たちは数字が好きです。

また、「コードメトリックの行は無関係である」ため、コードベースのサイズを説明するのではなく、何をしますか？

ばかげた例を挙げると、150行のコードベースと1億5000万行のコードベースには間違いなく違いがあります。そして、それを取得するのは難しい数字ではありません。