code-metrics - コードメトリクスの魅力は何ですか?

Question

最近、SO に関する「コードメトリクス」関連の質問を多数目にしましたが、その魅力は何なのか疑問に思う必要があります。最近の例を次に示します。

私の考えでは、コードレビューの代わりになる指標はありません。

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

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

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

注: 特定のスレッドで回答とコメントの両方でこれらの質問のいくつかを尋ねましたが、回答がありませんでした。そのため、おそらく何かが欠けているので、一般的にコミュニティに質問する必要があると考えました。メトリクスバッチジョブを実行して、他の人のコード (または自分のコード) を実際に二度と読む必要がないようになればいいのですが、それは実用的ではないと思います。

編集: 議論されている指標のすべてではないにしても、ほとんどの指標に精通していますが、それらのポイントを単独で、または任意の品質基準として見ているわけではありません。

score 87 · Accepted Answer

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

これらの指標の「唯一無二の受益者」のような「チーム」。
「指標」、それ自体が何かを意味するように。

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

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

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

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

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

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

言い換えれば、「メトリクスの魅力」に関するあなたの質問は、次の違いに言及している可能性があります。

「美しい」コード (ただし、常にコーダーの目に留まります)
「良い」コード (動作し、動作を証明できる)

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

ただし、次の場合:

後者の関数は安定した複雑さを持ち、コードカバレッジは 95% です。
一方、前者はますます複雑になり、カバー率が... 0% になります。

次のように主張できます。

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

要約すると、次のようになります。

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

: コードがより「美しい」かもしれないことを除いて、それほど多くはありませんが、それ自体は多くのことを意味するわけではありません...

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

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

score 22 · Accepted Answer

私は数ヶ月前に循環的複雑度を測定する一人の仕事として行ったプロジェクトを持っていました。それが、この種の指標に触れた最初の経験でした。

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

ルーチンの残りの半分については、プログラマーとしての私のプライドが発揮され、同じように、より単純で読みやすい方法で書き直そうとしました。それはうまくいき、私は顧客のイクロマティックな複雑さのしきい値に最も近づくことができました.

最終的には、ほとんどの場合、より優れたソリューションとよりクリーンなコードを思いつくことができました。これによってパフォーマンスが損なわれることはありませんでした (信じてください。私はこれに偏執的であり、コンパイラ出力の逆アセンブルを頻繁にチェックしています)。

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

メトリクスはガイドであり助けであり、それ自体が目的ではありません。

score 16 · Accepted Answer

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

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

前述の記事の著者（どうぞ、読んでください...それはあなたの時間の価値があります）は、次のように分類される30の最大CRAPスコアを提案します：

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

score 11 · Accepted Answer

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

急いで書かれたコード (つまり、洗練された解決策を見つける時間がなく、問題に複雑な解決策が必要だったからではありません)
テストされていないコード (誰もそのような獣のテストを書いていません)
何度もパッチが適用され、修正されたコード (つまり、ifs と todo コメントでいっぱい)
リファクタリングの主要なターゲット

score 9 · Accepted Answer

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

コードメトリクスは、ツールボックスに追加する別のツールです。それ自体はソリューションではなく、必要に応じて使用するためのツールにすぎません (もちろん、ボックス内の他のすべてのツールと一緒に!)。

score 6 · Accepted Answer

私が信じているコード指標が 1 つあります。

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

その数値が小さいほど良い。

score 6 · Accepted Answer

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

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

たとえば、一部のメトリックの極端な値は、問題の可能性を示しています。1000 行の長さのメソッドは、おそらく維持できません。単体テストのコードカバレッジがゼロのコードは、多くのテストを含む同様のコードよりも多くのバグを抱えている可能性があります。サードパーティのライブラリではない、リリース直前にプロジェクトに追加されたコードの大幅なジャンプは、おそらく特別な注意が必要です。

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

score 6 · Accepted Answer

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

ある意味では、少なくとも心理的には理にかなっています-評価または理解できないものについて、どうやって決定を下すことができるでしょうか? もちろん、最終的には品質を評価することはできませんが、その主題について知識がある (そして、少なくとも評価しようとしているものと同じくらい優れている) か、知識のある人に質問する必要があります。ワンステップ。

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

それが良い尺度だと言っているわけではありませんが、直感的に抵抗できないことがわかります. そして、あなたが指摘したように、おそらくいくつかの妥当なメトリクスがあります (500 以上の行のメソッドがたくさんあり、複雑さが高く、おそらく悪い)。しかし、私はこれを購入した場所に行ったことはありません。

score 5 · Accepted Answer

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

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

マネージャーは、生産性について正確な数値を取得していると感じているため (多くの場合、実際にはそうではありません)、人々をよりうまくジャグリングできるはずなので、それらの指標が好きです。

score 5 · Accepted Answer

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

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

一般に、それに適合しないメトリクスは、チームがそれに合わせて最適化することで影響を受けます。コードの行数を測定したいですか? なんてこった、彼らが何人書くことができるか見てください！コードカバレッジを測定したい場合は、私がそのコードをカバーするのを見てください。

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

score 5 · Accepted Answer

これはstan4jからの複雑性メトリクスです。

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

このツールと指標が気に入っています。メトリックを統計、指標、警告メッセージとして扱います。一部のメソッドまたは一部のクラスが実際に複雑なロジックを持っているため、それらが複雑になっている場合があります。それらを監視し、リファクタリングが必要かどうかを確認するか、慎重にレビューする必要がありますエラーが発生しやすいです。また、複雑なものから単純なものまで学ぶのが好きなので、ソースコードを学習するための分析ツールとしても使用しています。

複雑さの指標

循環的複雑度の指標

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

Average Cyclomatic Complexity アプリケーション、ライブラリ、パッケージツリー、またはパッケージのすべてのメソッドに対する Cyclomatic Complexity メトリックの平均値。

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

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

パッケージの Fat メトリックは、そのユニット依存グラフのエッジ数です。このグラフには、パッケージのすべての最上位クラスが含まれています。

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

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

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

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

トップレベルクラスの依存関係の脂肪 (脂肪 - ユニット) アプリケーションまたはライブラリのトップレベルクラスの依存関係の脂肪メトリックは、そのユニット依存関係グラフのエッジカウントです。このグラフには、アプリケーションまたはライブラリの最上位クラスがすべて含まれています。(合理的なアプリケーションの場合、大きすぎて視覚化できないため、構成ビューに表示できません。ユニット依存関係グラフは、パッケージに対してのみ表示される場合があります。)

score 2 · Accepted Answer

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

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

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

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

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

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

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

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

score 2 · Accepted Answer

メトリクスの小さな変化は意味があるとは思いません。複雑度 20 の関数は、複雑度 30 の関数よりも必ずしもきれいではありません。しかし、メトリクスを実行して大きな違いを探す価値があります。

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

score 2 · Accepted Answer

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

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

score 2 · Accepted Answer

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

score 2 · Accepted Answer

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

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

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

score 2 · Accepted Answer

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

score 1 · Accepted Answer

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

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

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

code-metrics - コード メトリクスの魅力は何ですか?

18 に答える 18

Related

Reference

code-metrics - コードメトリクスの魅力は何ですか?