ソースコードの有用な指標は何ですか？
ソースコード用にキャプチャするのに役立つメトリックは何ですか？
（Executable？）Lines of CodeまたはCyclomatic Complexityなどのメトリックは、品質保証にどのように役立ちますか、またはソフトウェア開発プロセスにとって一般的にどのように役立ちますか？
「コード行でソフトウェアの生産性を測定することは、飛行機の重さで飛行機の進行状況を測定するようなものです。」-Bill Gates
この件に関するジェフの投稿をご覧ください。
Joelからの古い、しかし良い投稿もあり、ソフトウェアメトリックに密接に関連しています。そのため、次のように読むことを強くお勧めします。 The Econ 101管理方法
私にとって重要な点は、ジェフを引用してこれです： 「メトリックの責任ある使用は、そもそもそれらを収集することと同じくらい重要です。」
コードメトリックについて私を混乱させるのは、それがそれ以上行われないということです。ほとんどの企業は、従業員、サプライヤー、システムの効率について報告していますが、誰もコードについて報告したくないようです。私は間違いなくコードの行数を増やすことが責任であると述べているが、あなたのコードが何をするかがより重要であるという回答に同意します。
コードの行数： '前述したように、これは重要な測定であり、最も真剣に、しかし各レベルで行う必要があります。関数、クラス、ファイル、およびインターフェースは、維持するのが難しく、長期的にはコストがかかる、あらゆることを行うコードを示す場合があります。コードの総行数とシステムの機能を比較することは、無限に困難です。それは多くのことを行うものである可能性があり、その場合、多くのコード行があります！
複雑さ：この測定は、これまで作業していないコードベースで行うのに適しているため、問題のある領域がどこにあるかを適切に示すことができます。有用な逸話として、自分のコードベースの1つで複雑さを測定しました。最も複雑な領域は、変更する必要があったときに最も多くの時間を費やしていた領域です。複雑さを軽減するための作業により、メンテナンス時間が大幅に短縮されました。管理者がこれらの測定値を手元に持っていれば、システムの特定の領域のリファクタリングの反復または再設計を計画できます。
コードの重複：これは、私にとっては非常に重要な測定です。コードの重複は非常に悪い兆候であり、システムの設計の低レベルでの深刻な問題か、コピー貼り付けである開発者のいずれかが原因であり、長期的には大きな問題を引き起こし、システムは保守不能になります。
依存関係グラフ悪い依存関係と循環依存関係を見つけることは、コードの重要な測定です。これはほとんどの場合、修正が必要な誤った高レベルの設計を示しています。誰かが電子メールライブラリ内でaddNumberを使用して財務計算を行っているため、1つの依存関係が不要な他の依存関係を大量に吸い込むことがあります。電子メールライブラリが変更され、財務が破綻すると、誰もがショックを受けます。すべてが1つのものに依存している場合は、保守が困難で設計が不適切な、あらゆることを行うライブラリを指すこともあります。
優れた測定は、システムのすべての機能のフットプリントが小さいことを常に示します。依存関係が少なく、複雑さが少なく、重複が少ない。これは、疎結合と高い凝集性を示しています。
この「ソースコードメトリックス」は決して死ぬことはありませんか？
コードの生のソース行（SLOC）は、最も古く、最も簡単で、最も基本的なメトリックです。
Halsteadは元々、大量のメトリックを提案しました。多くの人々が、スポイルスポーツが明らかな研究を行うまで、測定プログラムを書くのが楽しくて、すべてのハルステッド指標がSLOCと強く直接相関していることを示しました。
その時点で、SLOCの方が常に測定が容易であるため、Halsteadのメトリックは放棄されました。
品質保証のためのソースコード指標は、2つの目的を目指しています。
- 内部のバグが少ないコードを書く
- メンテナンスが簡単なコードを書く
どちらも、できるだけシンプルなコードの記述につながります。これの意味は：
- コードの短い単位（関数、メソッド）
- 各ユニットのいくつかの要素（引数、ローカル変数、ステートメント、パス）
- その他の多くの基準は多かれ少なかれ複雑です（Wikipediaの Software metric を参照）。
私の知る限りでは、見つかったバグの数は、コード行（おそらくチャーン）、モジュロ言語、プログラマー、およびドメインと直接相関しています。
バグと相関のある他の簡単で実用的な測定基準については知りません。
私がやりたいことの1つは、現在取り組んでいるさまざまなプロジェクトの数値の計算を開始することです。テストカバレッジ:: kLOCを行い、「知覚品質」について議論して、相関関係があるかどうかを確認します。
メトリックは、得られた回答をどう処理するかがわかっている場合にのみ役立ちます。本質的に、ソフトウェアメトリックは温度計のようなものです。 98.6°Fで何かを測定するという事実は、通常温度が何であるかを知るまで何も意味しません。上記の温度は体温には良いですが、アイスクリームには本当に悪いです。
役立つことができる一般的なメトリックは次のとおりです：
- バグが発見された/週
- バグは解決済み/週
- ＃要件の定義/リリース
- ＃実装された要件/リリース
最初の2つは傾向を測定します。バグを修正するよりも早く発見していますか？考えられる2つの結果：バグを修正するためのより多くのリソースが必要な場合と、追いつくまで新しい機能の実装を停止する必要がある場合があります。 2番目の2つは、あなたがどれだけ近づいているかを示しています。アジャイルチームはそれを「バーンダウン」チャートと呼んでいます。
Cyclomatic Complexityは興味深い指標です。基本概念では、関数/メソッド内の一意の実行パスの数です。単体テストの重い環境では、これはすべての実行パスを検証するために必要なテストの数に対応します。それにもかかわらず、96の循環的複雑度を持つメソッドがあるからといって、それが必ずしもバグのあるコードであることを意味するわけではありません。生成されたコードが（WPFまたはパーサージェネレーターを介して）この複雑なものを作成することは珍しくありません。メソッドのデバッグに必要な作業のレベルの大まかなアイデアを提供できます。
ボトムライン
実行するすべての測定には、次の定義が必要です。そうでないと役に立たなくなります。
- 「正常」とは何かの理解。これはプロジェクトの全期間にわたって調整できます。
- なんらかのアクションを実行する必要がある「通常」以外のしきい値。
- しきい値を超えたときにコードを処理するための計画。
取得する指標は、プロジェクトごとに大きく異なる場合があります。プロジェクト全体で使用するいくつかのメトリックがあるかもしれませんが、「通常」の定義は異なります。たとえば、1つのプロジェクトで週に平均5件のバグが発見され、新しいプロジェクトで週に10件のバグが発見されている場合、必ずしも何かが間違っているというわけではありません。今回は、テストチームがより注意深くなっている可能性があります。また、「正常」の定義は、プロジェクトの存続期間中に変更される可能性があります。
メトリックは単なる温度計であり、それをどのように使用するかはユーザー次第です。
ソースコードは負債ではなく資産です。 これを念頭に置いて、コードの行を測定することは、家を建てている間に費やした金額を追跡することに似ています。予算を超えないようにしたい場合は、これを行う必要がありますが、必ずしも1日あたり1000ドルを使うほうが1日50ドルを使うよりも良いとは限りません。あなたはそのお金のためにどれだけ家が建てられたのか知りたいでしょう。ソフトウェアプロジェクトのコード行についても同じです。
つまり、ソースコードを単独で測定することは役に立たないため、ソースコードに役立つメトリックはありません。
ソースコードは単にシーケンス、選択、繰り返しの組み合わせなので、私たちがこれまでに合理的に生産できると期待できるソフトウェアの最適な部分について説明すると、次のようになります。仕事に必要な最小限のコード行を使用し、変更に耐えるのに十分な柔軟性を備えた、ほぼ100％のテストコードカバレッジを持つソフトウェア。
KLOCカウントがパフォーマンスを測定するのに役に立たない（そして有害でさえある）理由を示す逸話。
数年前、チームと個人のパフォーマンスの唯一の指標としてKLOCカウントを使用する大規模なプロジェクト（社内では70人以上、顧客ではさらに30人以上）に取り組みました。
Y2Kの取り組み（どれくらい前にそれがあったかを伝えます:)）私たちのチームが担当していたコードのセクションを大幅にクリーンアップしました。私たちは約30.000行のコードを書いて、5人の作業に3か月の作業を費やしたわけではありませんでした。また、70,000行のコードを廃棄することにもなりました。これは、特に新しいコードと組み合わせると、3か月の作業に非常に適しています。
四半期の最終結果：-40.000行のコード。四半期後のパフォーマンスレビュー中に、四半期ごとに2万行のコードを生成するという生産性の要件を満たさなかったため、会社から公式の叱責を受けました（結局、ツールは-40.000行のコードを生成したことを示していました）。プロジェクトマネージャーとQAチームが介入せずに懲戒が覆されて表彰に置き換えられなかった場合、昇格、トレーニング、昇給などの理由で、パフォーマンスが低下し、バイパスされました。
数か月後（このような作業には時間がかかります）、会社は生産性基準を検討していると言われ、ファンクションポイント分析に基づいて新しいシステムを作成するために専門家のチームを雇いました。
誰も言及していないユニットテストのステートメント/決定カバレッジ（ユニットテストによって実行されるコードの割合）にまだ驚いています。
コードカバレッジは、アプリケーションの何パーセントが致命的に失敗しないかを知るのに役立ちます。その他の有用性は、単体テストの品質に依存します。
これらはあまり役に立ちませんabsolute進行状況のメトリックスですが、コードの状態の一般的な考えを与えるために使用できます。
特に、循環的複雑度は、特定のコードベースがどのようにモジュール化されているかを視覚化する上で役立つことがわかりました。これは、モジュールあたりのソースの数が少なく、多くのモジュールがあることを意味するため、一般的には複雑度を低くする必要があります。
通常、コミットは小さいほど良いです。これはSCMツールに関するものであり、コード自体ではありませんが、非常に測定可能なメトリックです。コミットが小さいほど、各変更をアトミックな単位として見ることが容易になります。特定の変更を元に戻し、問題が発生したときにピンポイントで示す方が簡単です。
コミットがビルドを中断しない限り...
私の仕事では、コードメトリックを使用する多くの状況があります。
コードの作成中
私の毎日の仕事で最大かつおそらく最も重要な用途は Checkstyle です。これは、Java開発者向けのツールであり、コードのメトリックを（他のものとともに）継続的にチェックします）私たちが定義した一連のルールと、コードがそれらのルールに準拠していない場所にフラグを立てます。コードを開発すると、メソッドが長くなる、複雑になる、または結合されるようになると、リアルタイムで通知され、前に戻ってそれをより良いものにリファクタリングすることを考えてください。
開発者は、すべての状況に適用されることはないため、すべての規則を完全に破ることができます。 「ルール」は、思考を刺激して「ねえ、これがこれを行うための最良の方法ですか？」と言うためにあります。
QA /コードレビュー中
コードレビューを実行するときに通常最初に行うことは、レビューしているコードのコードカバレッジを、カバーされているコード行を強調表示するコードカバレッジツールと組み合わせて確認することです。これにより、テストコードの徹底度がわかります。重要なコードが十分にテストされている限り、カバレッジが20％と100％のどちらでもかまいません。したがって、カバーされるパーセントは多少意味がありませんが、0％は、注意深く調べたいものとして痛い親指のように際立っています。
また、チームが同意したメトリックが「壊れている」場合は、それが問題ないことを開発者に同意するかどうか、または改善する方法を提案できるかどうかを確認します。新しいコードを書くために私たちのチームでこれらの開発メトリクスが合意されたことで、コードを改善する大きな道が開かれました。モノリシックなメソッドを大幅に減らし、 単一の責任の原則 の方がはるかに優れています。
レガシーコードの改善傾向改善したいレガシーコードがたくさんあります。どの時点でもメトリクスはほとんど役に立ちませんが、私たちにとって重要なことは、時間の経過とともにコードカバレッジが上がり、複雑さや結合などのものが下がることです。したがって、メトリックは継続的インテグレーションサーバーにプラグインされているため、時間をかけて調べて、正しい軌道に乗っていることを確認できます。
新しいコードベースに慣れるソースコードのメトリックの行を使用するのは、よく知らないコードベースを見るときだけですと。これにより、これまでに作業した他のプロジェクトと比較して、プロジェクトのおおよそのサイズをすばやく測定できます。他のメトリックを使用して、プロジェクトの品質についてさらに大まかなアイデアを得ることができます。
重要なのは、トレンドをトレンド、ディスカッション、または方法の出発点として使用し、正確な数値にそれらを宗教的に管理しないことです。しかし、私はそれらが適切に使用されたときに正しいコードを改善するのを助けることができると強く信じています。
私はしばしば巨大なC++パッケージで作業しており、リファクタリングする価値のある問題のあるコードを探す場合、 Cyclomatic Complexity または恐ろしい FanIn/FanOut は、通常、探すのに適した赤いフラグです。そこで問題を修正すると、通常、コードベース全体が改善されます。
もちろん、これらの数値は、何を見る価値があるかについてのヒントとしてのみ役立ちます。これをいくつかの難しいしきい値にしてから、ビルドを失敗させるか、コミットを拒否するのは、とんでもないことです。
Q：ソースコードをキャプチャするのに役立つメトリックは何ですか？
ビジネス：
A：工数
コーダーのスーパーバイザー：
A：関係ありません。今日は何でもやりましょう
コーダーの自尊心のために：
A：SLOC（コードのソース行）の数
コーダーの母親のために：
A：これらの柔らかいフレンチロールをもっと食べてお茶を飲む
以下のコメントに続きます...