ソースコードの有用なメトリックとは何ですか？[閉まっている]

ソースコードをキャプチャするのに役立つメトリックは何ですか？

たとえば（実行可能？）コード行や循環的複雑性などのメトリックは、品質保証にどのように役立ちますか、またはソフトウェア開発プロセスに一般的にどのように有益ですか？

「コードの行でソフトウェアの生産性を測定することは、飛行機の重さで進捗状況を測定するようなものです。」-ビル・ゲイツ

このテーマに関するジェフの投稿をご覧ください。

メトリクスメイドからの訪問

ソフトウェア工学：死んだ？

ソフトウェアメトリックスと密接に関連するJoelからの古くても良い投稿もあります。その読み物を強くお勧めします 。TheEcon 101 Management Method

私にとって重要な点は、ジェフを引用して、これです： 「メトリックの責任ある使用は、そもそもそれらを収集することと同じくらい重要です。」

コードメトリックスについて私を混乱させるのは、それ以上行われていないということです。ほとんどの企業は、従業員、サプライヤー、システムの効率性について報告していますが、誰もコードについて報告したくないようです。コードの行数を増やすことは不利ですが、あなたのコードが何をするかがより重要であると述べる答えには間違いなく同意します。

コードの行： 「前述したように、これは重要な測定であり、各レベルで最も真剣に取られるべきです。関数、クラス、ファイル、およびインターフェイスは、保守が難しく、長期的にコストがかかるすべてを実行するコードを示すことができます。コードの合計行数とシステムの動作を比較するのは無限に困難です。それは多くのことを行うものである可能性があり、その場合、多くのコード行があります！

複雑さ： この測定は、作業していないコードベースで行うのに適しています。また、問題のある領域の適切な指標を提供できます。有用な逸話として、私は自分のコードベースの1つで複雑さを測定しました。最も複雑な領域は、変更する必要があるときに最も時間を費やしていた領域です。複雑さの軽減に取り組んだ結果、メンテナンス時間が大幅に短縮されました。管理者がこれらの測定値を手元に持っている場合、システムの特定の領域のリファクタリングの反復または再設計を計画できます。

コードの複製： これは、私にとっては非常に重要な測定です。コードの複製は非常に悪い兆候であり、システムの設計の低レベルでの深刻な問題、またはコピーペーストである開発者のいずれかを指し、長期的に大きな問題を引き起こし、システムを維持できません。

依存関係グラフ 悪い依存関係と循環依存関係を見つけることは、コードの重要な測定です。これはほとんどの場合、修正が必要な誤った高レベルの設計を指します。誰かが電子メールライブラリ内でaddNumberを使用して財務計算を行っているため、1つの依存関係が不必要な他の依存関係を吸い込む場合があります。電子メールライブラリが変更され、財務が中断されると、誰もがショックを受けます。すべてが1つのものに依存している場合は、保守が難しく設計が不十分なあらゆるライブラリを指すこともあります。

適切な測定では、システムのすべての機能のフットプリントが小さいことが常にわかります。依存関係、複雑さ、重複の減少。これは、疎結合と高い凝集力を示しています。

この「ソースコードメトリック」は決して死ぬことはありませんか？

ソースコード行（SLOC）は、最も古く、最も簡単で、最も基本的なメトリックです。

Halsteadは元々、一連のメトリックを提案していました。スポイルスポーツが明らかな研究を行い、ハルステッドの各メトリックがSLOCと強く直接相関していることを実証するまで、多くの人々が測定プログラムを書くのをたくさん楽しんでいた。

SLOCは常に測定しやすいため、その時点でHalsteadのメトリックは破棄されました。

品質保証のソースコードメトリックは、2つの目的を目指しています。

• 内部にバグの少ないコードを書く
• メンテナンスが簡単なコードを書く

両方とも、可能な限り単純なコードの記述につながります。これの意味は：

• 短いコード単位（関数、メソッド）
• 各ユニットのいくつかの要素（引数、ローカル変数、ステートメント、パス）
• その他の多かれ少なかれ複雑な基準（Wikipediaのソフトウェアメトリックを参照）。

私の知る限り、発見されたバグの数は、コード行（おそらく解約）、モジュロ言語、プログラマー、およびドメインと直接相関しています。

バグと相関関係のある他の簡単で実用的なメトリックは知りません。

私がやりたいことの1つは、現在行っているさまざまなプロジェクトの数値の実行を開始することです。テストカバレッジ:: kLOCで、「知覚品質」について話し合い、相関関係があるかどうかを確認します。

メトリックは、得られた回答をどう処理するかを知っている場合にのみ役立ちます。本質的に、ソフトウェアメトリックは温度計のようなものです。あなたは何を知っているまで、あなたは98.6°Fで何かを測定するという事実はありません平均何もしない、通常の温度です。上記の温度は体温には良いが、アイスクリームには本当に悪い。

役立つ可能性のある一般的なメトリックは次のとおりです。

• 発見されたバグ/週
• 解決されたバグ/週
• ＃要件の定義/リリース
• ＃要件の実装/リリース

最初の2つは、傾向を測定します。バグを修正するよりも早く見つけていますか？考えられる2つの結果：バグを修正するためにさらにリソースが必要な場合と、追いつくまで新しい機能の実装を停止する必要がある場合があります。2番目の2つは、あなたがどれだけ近くにいるのかを示しています。アジャイルチームはそれを「バーンダウン」チャートと呼びます。

循環的な複雑さは興味深い指標です。基本概念では、関数/メソッド内の一意の実行パスの数です。単体テストの重い環境では、これはすべての実行パスを検証するために必要なテストの数に対応します。それでも、Cyclomatic Complexityが96のメソッドを持っているからといって、必ずしもバグのあるコードであるとは限りません。または、妥当な信頼性を提供するために96個のテストを記述する必要があります。生成されたコードが（WPFまたはパーサージェネレーターを介して）この複雑なものを作成することは珍しくありません。メソッドのデバッグに必要な作業レベルの大まかなアイデアを提供できます。

ボトムライン

行うすべての測定には、以下を定義する必要があります。定義しないと、役に立ちません。

• 「正常」とは何かの理解。これは、プロジェクトの存続期間中に調整できます。
• 何らかのアクションを実行する必要がある「通常」以外のしきい値。
• しきい値を超えたときにコードを処理するための計画。

取得するメトリックは、プロジェクトごとに大きく異なる場合があります。プロジェクト全体で使用するいくつかのメトリックがありますが、「通常」の定義は異なります。たとえば、1つのプロジェクトが1週間に平均5個のバグを発見し、新しいプロジェクトが1週間に10個のバグを発見している場合、必ずしも何かがおかしいとは限りません。今回はテストチームがより細心の注意を払っているのかもしれません。また、「通常」の定義はプロジェクトの存続期間中に変更される場合があります。

メトリックは単なる温度計であり、それをどうするかはあなた次第です。

ソースコードは資産であり、負債ではありません。それを念頭に置いて、コードの行を測定することは、家を建てるときに費やしたお金を追跡することに似ています。予算を抑えたい場合は、それを行う必要がありますが、1日あたり$ 50を使うよりも1日あたり$ 1000を使う方が良いとは限りません。そのお金のためにどれだけの家が建てられたかを知りたいでしょう。ソフトウェアプロジェクトのコード行でも同じです。

要するに、ソースコード自体を測定することは役に立たないため、ソースコードに役立つメトリックはありません。

ソースコードは、シーケンス、選択、繰り返しの単なる組み合わせであるためです。合理的に生産できると予想できる最適なソフトウェアについて説明すると、次のようになります。ジョブを実行するのに必要な最小限のコード行を使用して、ほぼ100％のコードカバレッジをテストし、しかも変更に耐えるのに十分な柔軟性を備えたソフトウェア。

KLOCカウントがパフォーマンスを測定するのに役に立たない（そして有害でさえある）理由を示す逸話。

数年前、私はチームと個人のパフォーマンスの唯一の尺度としてKLOCカウントを使用する大規模プロジェクト（当社の70人以上、顧客の30人以上）に取り組みました。

Y2Kの取り組みのために（どれくらい前にそれがあったかをお伝えします:)）、チームが担当したコードのセクションの大規模なクリーンアップを行いました。最終的には、約30.000行のコードを作成するリリースになりましたが、5人で3か月の苦労はありません。また、さらに70.000行のコードを廃棄することになりました。これは、特に新しいコードと組み合わせて、3か月間の作業で非常に良い仕事でした。

四半期の最終結果：-40.000行のコード。四半期後のパフォーマンスレビュー中に、四半期ごとに2万行のコードを生成するという生産性要件を満たしていないことについて会社から公式のre責を受けました（結局、ツールは、40.000行のコードを生成したことを示していました）プロジェクトマネージャーとQAチームが介入してre責を覆し、称賛に取って代わられなかった場合、プロモーション、トレーニング、昇給などのために私たち全員が成果の低いものとしてリストされ、バイパスされていました。

数か月後（そのようなことには時間がかかります）、会社は生産性の基準を見直していて、機能ポイント分析に基づいて新しいシステムを作成するために専門家チームを雇ったと言われました。

ユニットテストのステートメント/意思決定カバレッジ（ユニットテストで実行されたコードの割合）に誰も言及していないことにまだ驚いています。

コードカバレッジは、アプリケーションの何パーセントが破局的に失敗しないかを知っているので便利です。残りの有用性は、単体テストの品質に依存します。

通常、コミットが小さいほど良いです。これはSCMツールに関するものであり、コード自体ではありませんが、非常に測定可能なメトリックです。コミットが小さいほど、各変更をアトミック単位として見やすくなります。特定の変更を元に戻し、問題が発生したときに特定するのが簡単です。

コミットがビルドを中断しない限り...

これらは、進行状況の点で非常に有用な絶対メトリックではありませんが、コードの状態の一般的なアイデアを提供するために使用できます。

特にCyclomatic Complexityは、特定のコードベースがどの程度モジュール化されているかを視覚化するのに役立つことがわかりました。これは、モジュールごとのソースの数が少なく、多くのモジュールが存在することを意味するため、通常は複雑さを低くしたいでしょう。

私は頻繁に巨大なC ++パッケージで作業しますが、Cyclomatic Complexityや恐ろしいFanIn / FanOutをリファクタリングする価値のある問題のあるコードを探す場合、通常は非常に良いレッドフラグを探します。そこで問題を修正すると、通常、コードベース全体が改善されます。

もちろん、これらの数字は、見る価値があるもののヒントとしてのみ使用できます。ビルドを失敗させるか、コミットを拒否するために、これをある程度厳しいしきい値にすることはばかげているでしょう。

私の仕事には、コードメトリックを使用する多くの状況があります。

コードを書いている間

私の毎日の仕事で最も大きく、おそらく最も重要な使用法はCheckstyleです。これは、Java開発者向けのツールです。これは、定義済みのルールセットに対してコードのメトリック（特に）を継続的にチェックし、コードがそうでない場所にフラグを立てますそれらのルールを順守します。コードを開発するときに、メソッドが長くなり、複雑になり、結合された場合、リアルタイムで通知され、後戻りしてより良いものにリファクタリングすることを考えることができます。

開発者はすべての状況に適用されることはないため、すべてのルールを完全に破ることができます。「ルール」は、思考を刺激し、「これがこれを行う最善の方法ですか？」と言うためにあります。

QA /コードレビュー中

コードレビューを実行するときに最初に行うことは、通常、レビュー対象のコードのコードカバレッジを、カバーされているコード行を強調表示するコードカバレッジツールと共に確認することです。これにより、テストコードがどの程度徹底しているかについての一般的な考えが得られます。重要なコードが十分にテストされている限り、カバレッジが20％か100％かはあまり気にしません。したがって、カバーされている割合はいくぶん無意味ですが、0％は確かに親指を痛めたように際立っています。

また、チームによって合意されたメトリックが「壊れている」場合、それが問題ないことを開発者に同意するかどうか、または改善方法を提案できるかどうかを確認します。新しいコードを記述するためにこれらの開発指標をチームで合意することで、コードの改善に大きな道が開かれました。私たちはモノリシックな方法をはるかに少なく記述し、単一の責任原則ではるかに優れています。

レガシーコードのトレンド改善改善したいレガシーコード がたくさんあります。どの時点でもメトリックは役に立たないが、私たちにとって重要なのは、時間の経過とともにコードカバレッジが上昇し、複雑さや結合などが低下することです。したがって、メトリックは継続的インテグレーションサーバーにプラグインされるため、時間をかけて適切な方向に進むことができます。

新しいコードベースを 理解するソースコードメトリックの行を使用するのは、よく知らないコードベースを見るときだけです。これにより、私が作業した他のプロジェクトと比較して、プロジェクトの大まかなサイズをすばやく測定できます。他のメトリックを使用して、プロジェクトの品質についてさらに大まかなアイデアを得ることができます。

重要なことは、トレンド、ディスカッション、または今後の方法の出発点としてメトリックを使用し、正確に数値を管理しないことです。しかし、適切に使用すれば、適切なコードの改善に役立つと強く信じています。

Q：ソースコードをキャプチャするのに役立つメトリックスは何ですか？

ビジネス用：

A：工数

コーダーのスーパーバイザーの場合：

A：関係ありません。今日は何でもしましょう

コーダーの自尊心の場合：

A：SLOCの数（コードのソース行）

コーダーの母親の場合：

A：これらの柔らかいフレンチロールをもっと食べて、お茶を飲む

以下のコメントに続きました...

要確認：すべてのコードは、少なくとも1命令削減できます。すべてのコードには少なくとも1つのバグがあります。したがって、すべてのコードを、機能しない単一の命令に減らすことができます。お役に立てば幸いです！