私は、大きなコード ベースの循環的複雑度を測定して遊んでいます。
循環的複雑度は、プログラムのソース コードを通過する線形に独立したパスの数であり、選択した言語用の無料ツールが多数あります。
結果は興味深いものですが、驚くべきことではありません。つまり、私が最も毛深いとわかっている部分は、実際には最も複雑でした (評価が 50 を超えていました)。しかし、私が便利だと思っているのは、リファクタリングを開始する場所を決定する際に参照できるものとして、具体的な「悪い」番号が各メソッドに割り当てられていることです。
循環的複雑度を使用していますか? あなたが見つけた最も複雑なコードは何ですか?
私たちは容赦なくリファクタリングし、コードを「ヒット リスト」に載せる指標の 1 つとして循環的複雑度を使用します。1 ～ 6 は複雑さのフラグを立てません (ただし、他の理由で疑問視される可能性があります)。7 ～ 9 は疑わしいものです。
私たちが目にした最悪の事態は、私たちが引き継がなければならなかったレガシー コードの巨大な if-else-if チェーンからの 87 でした。
実際、循環的複雑度は、メソッド レベルのしきい値を超えて使用することができます。手始めに、複雑度の高い 1 つの大きなメソッドが、複雑度の低いいくつかの小さなメソッドに分割されることがあります。しかし、コードベースは本当に改善されたのでしょうか? 確かに、これらすべてのメソッド名によって多少読みやすくなるかもしれません。しかし、条件ロジック全体は変わっていません。また、条件をポリモーフィズムに置き換えることで、条件ロジック全体を削減できることがよくあります。
単なるメソッド分解では緑色にならないメトリックが必要です。私はこれをCC100と呼んでいます。
CC100 = 100 * (コードベースの循環的複雑度の合計) / (コードの合計行数)
big-O が有用であるのと同じように、それは私にとって有用です: 私はそれが何であるかを知っており、それを使用してメソッドが良いか悪いかについて直感を得ることができますが、毎回計算する必要はありません。私が書いた関数。
LOC のような単純な指標は、ほとんどの場合、少なくとも同様に優れていると思います。機能が 1 つの画面に収まらない場合、その機能がどれほど単純であってもほとんど問題になりません。関数が 20 個のパラメーターを取り、40 個のローカル変数を作成する場合、その循環的複雑度が 1 であっても問題ありません。
C++ テンプレートやメタプログラミング手法とうまく連携できるツールが登場するまでは、私の状況ではあまり役に立ちません。とにかくそれだけは覚えておいてください
「数えられるすべてのものを測定できるわけではないし、測定できるすべてのものを数えられるわけでもない」アインシュタイン
したがって、このタイプの情報はすべて、人によるフィルタリングも通過することを忘れないでください。
最近使い始めました。NDepend を使用して静的コード分析を行い、循環的複雑度を測定します。私は同意します。リファクタリングの方法を特定するのはまともな方法です。
残念ながら、オフショアの開発者によって作成されたいくつかのメソッドで # が 200 を超えていることがわかりました。
複雑さは見ればわかります。この種のツールの主な用途は、注意を逃していたコードの部分にフラグを立てることです。
私は自分のコードの循環的複雑度を頻繁に測定しています。やりすぎているコードの領域を見つけるのに役立つことがわかりました。コード内のホット スポットをツールで指摘することは、SRP に従っていないメソッドを見つけようとして何千行ものコードを読む必要がある場合よりも、はるかに時間がかかりません。
しかし、他の人のコードで循環的複雑度分析を行うと、循環的複雑度が 100 のコードを見つけると、通常、フラストレーション、不安、および一般的な怒りの感情につながることがわかりました。数千行のコードを含むメソッドを作成しなければならない理由は何ですか?!
リファクタリングの候補を特定するのに役立ちますが、判断を維持することが重要です。剪定ガイドの kenj0418 の範囲をサポートします。
CRAP4Jと呼ばれる Java メトリックがあり、循環的複雑度と JUnit テスト カバレッジを経験的に組み合わせて単一のメトリックを作成します。彼は自分の経験式を改善しようと研究を続けています。どこまで広がっているかはわかりません。
はい、私たちはそれを使用しており、私もそれが役立つことを発見しました. 飼いならすべき大きなレガシーコードベースがあり、驚くほど高い循環的複雑性があることがわかりました。（1つの方法で387！）。CC は、リファクタリングする価値のある領域を直接示します。C++ コードでは CCCC を使用します。
循環的複雑性は、加工された複雑性と呼ばれるものの構成要素の 1 つにすぎません。しばらく前に、コードの複雑さのいくつかの側面をまとめた記事を書きました。
コードの複雑さを効率的に処理するには、ツールが必要です。ツールNDepend for .NET コードを使用すると、循環的複雑性、ネストの深さ、メソッドの結合の欠如、テストによるカバレッジなどのコード メトリックを含む、コードの複雑さの多くの側面を分析できます。
依存関係の分析を含め、質問専用の言語 ( Code Query Language ) を含め、コードの何が複雑で、ルールを記述しますか?
After understanding what it means, I now have started to use it on a "trial" basis. So far I have found it to be useful, because usually high CC goes hand in hand with the Arrow Anti-Pattern, which makes code harder to read and understand. I do not have a fixed number yet, but NDepend is alerting for everything above 5, which looks like a good start to investigate methods.
+1 kenj0418 のヒット リストの値。
私が見た中で最悪だったのは 275 でした。200 を超える他のいくつかの CC は、はるかに小さな CC にリファクタリングできました。彼らはまだ高かったが、彼らはさらに押し戻された. 275 のビーストにはあまり運がありませんでした。それは (おそらく今でも) 複雑すぎる if ステートメントと switch ステートメントのウェブでした。彼らがシステムを再構築することを決定したとき、それは唯一の真の価値です。
私が快適だった高CCの例外は工場でした。IMO、それらは高い CC を持っているはずですが、単純なオブジェクトの作成と返却のみを行っている場合に限ります。
しばらく使用していませんでしたが、以前のプロジェクトでは、他の誰かのコードの潜在的な問題点を特定するのに本当に役立ちました (もちろん私のものではありません!)。
チェックアウトする領域を見つけると、ロジックといくつかの非常に奇妙な WTF コードに関する多数の問題がすぐに見つかりました (GOTOS もたくさんあります!)。
循環的複雑度は、おそらく多くのことを行っている領域を示すのに最適であり、したがって単一の責任の原則を破ります。これらは理想的には複数の機能に分割する必要があります
残念ながら、このようなメトリクスが最も欲しいプロジェクトの言語であるLPCについては、実際には、それを作成するための無料のツールがたくさんありません。いいえ、私にはあまり役に立ちません。