コードの「循環的複雑度」とはどういう意味ですか？
コードの静的分析は初めてです。私のアプリケーションの循環的複雑度は17,754です。アプリケーション自体は、わずか37,672行のコードです。コードの行に基づいて複雑さは高いと言っても意味がありますか？ Cyclomaticの複雑さは私に何を言っているのですか？
Cyclomaticの複雑さは私に何を言っているのですか？
循環的複雑度は、コード行の測定ではなく、モジュールを通る独立したパスの数です。 17,754の循環的複雑度は、アプリケーションに17,754の一意のパスがあることを意味します。これには、通常、アプリケーションの理解とテストがいかに難しいかという点で、いくつかの影響があります。たとえば、循環的複雑度は、適切に記述されたテストを想定して、100％のブランチカバレッジを達成するために必要なテストケースの数です。
良い出発点は 循環的複雑度に関するウィキペディアの記事 かもしれません。疑似コードのスニペットがいくつかあり、循環的複雑度がどのようなものであるかを示すいくつかのグラフがあります。詳細を知りたい場合は、 また、McCabeのサイクロマティック複雑度を定義した論文も参照してください 。
私のアプリケーションの循環的複雑度は17,754行です。アプリケーション自体は、わずか37,672行のコードです。コードの行に基づいて複雑さが高いと言うことは有効ですか？
どういたしまして。数行のコードとループ内にネストされた多数の条件文を含むアプリケーションは、極めて高い循環的複雑性を持つ可能性があります。一方、条件がほとんどないアプリケーションは、循環的複雑度が低い場合があります。それは非常に単純化しすぎですが、アイデアは理解できたと思います。
アプリケーションが何をしているかについての知識がなければ、循環的複雑度が高くなるのは普通のことです。ただし、アプリケーションレベルだけでなく、クラスまたはメソッドレベルで循環的複雑度を測定することをお勧めします。これは、概念的には少し管理しやすいと思います。大規模なアプリケーションを介したパスよりも、メソッドを介したパスを視覚化または概念化する方が簡単です。
循環的複雑度は、コードをリファクタリングする必要があるかどうかを判断する方法です。コードが分析され、複雑度の数値が決定されます。複雑さは分岐（ステートメントなど）によって決定されます。複雑さは、ループなどの入れ子や、使用するアルゴリズムによっては他の要因を考慮に入れることもできます。
数値はメソッドレベルで役立ちます。より高いレベルでは、それは単なる数です。
17,754という数値は、プロジェクトレベルの複雑さ（合計コード）を示しますが、それほど意味はありません。
クラスおよびメソッドレベルの複雑さを掘り下げることで、コードを細かくメソッドにリファクタリングまたは再設計して複雑さを排除する必要のある領域が決定されます。
1つのメソッドで50ケースのCASEステートメントを考えてみます。たぶん、各州には異なるビジネスロジックがあります。これにより、循環的複雑度が50になります。50の決定点があります。 CASEステートメントは、分岐ロジックを取り除くために、ファクトリパターンを使用して再設計する必要がある場合があります。場合によっては、リファクタリング（メソッドをより小さな部分に分解）することができ、場合によっては、再設計のみで複雑さが軽減されます。
一般に、メソッドレベルの複雑さの場合：
- <10メンテナンスが簡単
- 11-20メンテナンスが難しい
- 21+リファクタリング/再設計の候補
また、複雑度が高くなるとコードの単体テストが難しくなることも考慮してください。
単一のメソッドで私が見た最高の複雑さは560でした。1つのメソッドのifステートメントは約2000行でした。基本的にメンテナンス不能、テスト不可能、潜在的なバグがたくさんあります。その分岐ロジックに必要なすべての単体テストケースを想像してみてください。良くない。
すべてのメソッドを20未満にしてみてください。メソッドをリファクタリングして複雑さを軽減するにはコストがかかることを認識してください。
これは、アプリケーション内の個別のパスの数です。 [〜＃〜] cc [〜＃〜] に関するIBMの記事をご覧ください。
それは高いようですが、あなたの場合、それはあなたのすべてのクラスとメソッドのすべてのあなたのメソッドのCCの追加です。コードの構造がわからないので、私の例ははるかに広がっていますが、37672行のコードを持つ1つのモンスターメソッド、または約10行のコードを持つ3767メソッドもあるでしょう。つまり、アプリケーションレベルではこのインジケーターはあまり意味がありませんが、メソッドレベルでは、コードをより小さなメソッドに最適化/書き直して、エラーが発生しにくくするのに役立ちます。
私が何度も個人的に読んだのは、CCが10を超えるメソッドは欠陥のリスクが高いということです。
私は Sonar を使用してアプリケーションのコード品質をテストします。デフォルトで、+ 10 CCのメソッドがある場合は警告が表示されると思います。それでもそれは何も意味しないかもしれません。具体的な例の1つ：Eclipseを使用して、Beanのプロパティに基づいてequalsメソッドを生成すると、CCはすぐに屋根の上に移動します...