2009-03-01 8 views
5

私は最近、プロジェクトを分析し、設計メトリックに基づいてリスクが最も高い のクラスを20個特定しました。ソースモニタを使用してプロジェクトを分析する

私はこのプロジェクトの分析を開始しました。私は最大複雑度のクラスを選ぶことに決めました。私は最大の複雑さ以外に何かを見ているべきですか?文、クラス、メソッド/クラス、最大深度などの数。 私は正しい方向に向かっていますか?他に何を見なければならないのでしょうか?

ありがとうございます。

答えて

5

私は主に、最大複雑度、最大深度、およびステートメントの数を調べます。この3つのメトリックは、実際にひどく書かれたメソッド(長く、深くネストされた、多くの決定と依存関係)を検出します。

これらの3つのメトリックのそれぞれについてSourceMonitorレポートをソートし、上位20-30クラスを書き留めてから、3つのリストすべてでランクが高いものを選択します。

+0

多分これはプロジェクト言語に依存しますが、C++では* Display Method Metrics ... *が特定のチェックポイントに対して最良の結果を提供することがわかります。 BTW:これらの3つの基準(「wc」:複雑さの重み、「wd」:深さの重み、ws:ステートメントの重み)を重み付けして、最大値(wc * C + wd * D + ws * S) 'か、これは実用的ではありませんか? – Wolf

+1

@ウルフ私はあなたがものを過度に複製していると思う。このツールは、さまざまな基準でメトリックを提供します。コードの状態を最もよく表しているメトリックを選択し、それらのメトリックに従って最悪のソースファイルを処理します。 この問題の正確な数式はないと思います。 – zendar

1

これは始めるのに適していますが、リスクはユニットテストが含まれているコードの量とも結びついています。

たとえば、cycを使用する関数。 100%のユニットテストコードカバレッジを持つ20の複雑さは、cycを持つ関数よりも安全です。単体テストなしで10の複雑さ。

+0

100%のカバレッジ関数は、テストなしのカバレッジ関数よりも "正しい"可能性が高くなります。複雑さが増すということは、それを変更または拡張するためにより多くの作業(労力)を必要とする可能性が高いことを意味します。 – Schollii

+0

真ですが、ソースモニタはテストカバレッジの測定をサポートしていません。多分、タスクを最適に解決する最良のツールではないかもしれません。*「設計メトリクスに基づいてリスクが最も高い20のクラスを特定する」* – Wolf

関連する問題