最近、Eclipse Metrics Plugin をインストールし、プロジェクトの 1 つのデータをエクスポートしました。
これらの素敵なグラフがあるのはとても良いことですが、それらが何を意味するのかをもっと深く理解したいと思っています. メトリクスの定義は、それが実際に何を意味するかを伝えるだけです。
すべてのデータの意味をよりよく理解し、必要に応じてコードを改善する方法を理解するのに役立つ優れたリソース、書籍、Web サイトなどを知っている人はいますか?
コードの行やメソッドごとの行ではなく、遠心性カップリングや循環的複雑性などに興味があります。
コードメトリクス（ソフトウェアメトリクスと呼ばれることもあります）は、どこを改善できるかという点で価値のあるデータを提供するとは思いません。
コードメトリクスを使用すると、1時間にどれだけのコードを記述したかなどを確認できますが、それを超えると、記述されたコードの品質、ドキュメント、およびコードカバレッジについて説明します。彼らはあなたが実際に測定することができないところを測定するためのほぼ一週間の試みです。
コードメトリックはまた、明らかにコーディングが少ないため、より困難な問題を解決するプログラマーを識別します。それでも彼らは難しい問題を解決し、後輩のプログラマーがたくさんのがらくたコードをむち打ちするのはよさそうだ。
メトリックを使用する別の例は、非常に人気のあるOhlohです。彼らはメトリックを使用して、オープンソースプロジェクトに値札を付けます（行数などを使用）。これは、想像できるように、それ自体が地獄のように欠陥のある試みです。
ウィキペディアのエントリはトピックに関する全体的な洞察を提供していると言っても、本当に素晴らしいWebサイトや本であなたの質問にもっと協力的な方法で答えないことを残念に思いますが、私は大ファンではないというドリフトを得たに違いありません。:)
改善を支援するために採用するものは、コードやドキュメントなどに関して、継続的インテグレーションとある種の標準への準拠です。それがあなたが改善できる方法です。指標は、会議の目玉にすぎません。「すでにコーディングしているように見えます」。
アップデート
さて、私のポイントは、効率的な結合または循環的複雑度でさえ、何かが間違っていることを示している可能性がありますが、間違っている必要はありません。クラスをリファクタリングするための指標になる可能性がありますが、いつかを示す経験則はありません。
ほとんどの場合、500行以上のコード、リファクタリング、DRYプリンシパルなどのルールがより適切です。時にはそれはそれと同じくらい簡単です。
循環的複雑度がフローチャートにグラフ化されているため、目を見張るものになる可能性があることをお伝えします。ただし、繰り返しになりますが、慎重に使用してください。
私の意見では、メトリクスはコードベースの問題点を見つける優れた方法です。また、時間をかけて改善する必要がある理由を上司に示すのにも非常に役立ちます。
これは私が書いた投稿です: http://blog.jorgef.net/2011/12/metrics-in-brownfield-applications.html
役立つことを願っています