コード品質を定量化する方法
私のビジネスユニットには膨大な数の開発者がいます（約100人）。さまざまな理由により、開発者はほとんど品質よりも配信に専念しています。質の悪いコードはすでに私たちを傷つけ始めています。バグの特定が困難になりました。コードは壊れやすくなっています。単体テストは要件から完全に切り離されています。等々。
私は経営陣と密接に協力しています。この時点で、優れたコードに報いるための戦略を考案したいと思います。以下に挙げたいくつかのパラメータを客観的に測定する方法を考えたいと思います。私がこれを測定したいのは、開発者が良質のコードを書いたときに認識され、高く評価される環境を作るためです。 （私はこれの管理サポートを得ることができます）。この時点で、管理はコードの品質を測定するための番号なしで切断されています。
- コードの読みやすさ
- 単体テストと要件との相関度（カバレッジではなく、開発者はコードを無意味な単体テストでカバーできます）
- シンプルなデザイン
主にC＃で開発しています（モバイル、ウェブ、デスクトップアプリ）
更新1：2019年11月14日
素晴らしい答えに基づいて、私は品質を測定するための多くの手段があることを理解しました、そして、それらはすべてピンチソルトでとられなければなりません。 Telastyn による素晴らしい insight でした。 「メジャーがターゲットになると、良いメジャーではなくなります」。これは私のためにそれを釘付けにしました。
この時点で、コードの品質（特に読みやすさ）の人間的要素を考慮する必要があると確信しています。 （主観的かつ客観的に）コード品質の測定に関心を持たせる方法は、本当に私が直面している課題です。
この時点で、優れたコードに報いるための戦略を考案したいと思います。
それはいけません。 グッドハートの法則 はすぐに効果を発揮し、客観的な測定基準は、開発者が他のすべての除外に焦点を合わせるものになります。
管理が実際に作成しているものから切り離されている場合、またはコードに洞察を持っているdoチームリーダーを信頼していない場合、メトリックはありませんそれを修正するつもりはありません。コードの問題ではなく、管理の問題があります。
基本
品質を測定する方法はたくさんあります。どれも完璧ではありません。絶対的な言葉で考え始めると、新しい問題が発生する可能性があります。次に、一般的に使用されるいくつかのメトリックを示します。
- 循環的複雑度
- テストカバレッジ
- クラス/メソッドごとのLOC
- 重複カウント
標準への準拠や最小テストカバレッジなど、「ゲート」として使用できるバイナリメジャーもあります。
自分で三振するのではなく、 SonarQube などを試すことをお勧めします。これにより、ダッシュボードに組み込むことができる多くの標準とメトリックが得られます。
コードを実行して結果を分析し、経営陣と共有することをお勧めします。次に、いくつかのルールを微調整することを検討し、これを使用してビルドを中断できます。配信用のビルドサーバーと管理プロセスがあると仮定します。ただし、この部分には経営陣の賛同が必要です。
ネーミング
命名についてのあなたのアイデアによっては、これが実行できない場合があります。変数の名前が適切かどうかをプログラムで判断する方法があるかどうかはわかりません。私は物事を考えることができます
- 名前の長さ（長すぎる、短すぎる）
- 名前の数字（悪い符号）
- 辞書の単語である必要があります
しかし、最終的には、名前が意味のあるものであることを確認するために、おそらくレビューチームが必要です。チームの誰かがあなたの懸念に同意しますか？
テスト中
これは少し物議を醸すかもしれませんが、単体テストを要件に関連付ける必要はないと主張します。単体テストの要点は、コードが想定どおりに機能することを確認することではありません。ポイントは、コードが意図したとおりに機能することを確認することです。たとえば、合計関数のテストでは、合計が正しく計算されることを確認する必要があります。ユニットテストでは、要件が合計を計算することであるかどうかは関係ありません。これは微妙な違いですが、単体テストの記述方法に大きな違いをもたらします。
要件のテストは別のレイヤーで行う必要があります。このために単体テストを使用している場合は、コンポーネントレベルまたはアプリケーションレベルで機能テストスイートと回帰テストスイートを組み合わせる必要があります。
カバレッジを超えた単体テスト指標の課題は、それらが意味があるかどうかです。ブランチカバレッジを使用することは、ラインカバレッジよりも優れていると思いますが、テストでパスを実行するだけで何もチェックできない場合。
頭に浮かぶアイデアの1つは、ここでモックまたはファズテストツールを使用できる可能性があるということです。単体テストを取り、悪いメソッド定義に対して実行します。そのシナリオでは、優れたテストは失敗するはずです。
可視性
- すべてのコードベースが共有され、チームに表示されることが重要です。
- ピアレビューを促進する。
- ペアプログラミングを促進します。
- 静的コードアナライザーを使用します。このツールは構成可能であり、調整可能なルールのプリセットセットが付属しています。
- SCAを継続的インテグレーションワークフローに統合し、誰にでも見える自動セマフォレポートを公開します。
- コードの品質は100％計測可能ではありませんが、クラスとメソッドの長さ、循環的複雑度、凝集度、および大量のパラメーターを測定し、ユニットテストの結果とともに、緑色、黄色、または赤色のライトに変える可視レポートがあります。は、プログラマーに、コードがクリーンで、コードベースの全体的な品質を上手くまとめているかどうかを示します。
しかし、私にとって、魔法の言葉はvisibilityです。一般的に人々は観察されたときによりよく振る舞う傾向があり、プログラマーも例外ではありません。コードは誇りに思うべきものであり、ウォータークーラーについて話し合うべきものです。コードを話し、コードを呼吸し、コードを考える。
また、カバレッジが100％であっても、要件が満たされていることをテストするのではなく、単体テストを行うことについて何か言います。要件やストーリーのテストが受け入れテストや統合テストの問題であるため、特定の機能を満たすために記述されたメソッドの名前と量を必ずしも推測できるとは限りません。一部の単体テストでは、特定の入力を与えられた関数が期待される結果を返すかどうかをテストできます。これは、事前に計算された何千もの値のリスト全体に対して実行できます。渡せないコードは壊れています。それは確かに要件の実現を強制していると思います。ただし、統合テスト、ストレステスト、および受け入れテストの問題である他の要件もあります。
BLUF：品質を測定および改善するためにできるあらゆるツールを使用しますが、それらの制限を理解します。あなたの例のシナリオでは、ピアレビューのためのいくつかの標準が必要であるように見えます。
品質は、定義上、あいまいな概念です：
同様の種類の他のものに対して測定されたものの標準。何かの卓越性の程度。 （Googleの定義）
コンピュータサイエンスでは、常に定量的な数値を定性的な概念（関連性スコア、一致の可能性など）に提供しますが、これらのスコアは、実行された特定のデータセットの外部で互いに比較できる形式になっていることはめったにありません。
コードの品質は非常に複雑なテーマであり、「ベストプラクティス」を盲目的に実行するコードを分離するhuman要素を無視し、本当に高品質のコードは、本当に欲しいものを無視することです。品質と一貫性を向上させるために必要なツールはいくつかありますが、コードが品質であるかどうかを信頼できる方法で説明できるツールはありません。
例えば：
- 循環的複雑度：発生する可能性のあるコード分岐の尺度であり、関数またはメソッドレベルで最も役立ちます。分岐やループが多いほど、その関数のロジックをたどることが難しくなります。
- 保守性インデックス：（ math ）は、循環的複雑度、コードのソース行、およびHalsteadボリュームと呼ばれるものの複合スコアです。おそらく、より優れたメトリックの1つですが、コードの読みやすさや理解しやすさについてはカバーできません。値をパーセントのように扱います。
- LintまたはStatic Analysisツール（SonarQubeなど）：ルールに体系化されたいくつかの「ベストプラクティス」を提供します。これらの規則に従うコードは、従わないコードよりも通常追跡および保守が容易です。通常、ルールは製品に合わせてカスタマイズする必要がありますが、少なくとも全員が同じようにコードをフォーマットすると読みやすくなります。
- 単体テストとビジネステスト：コードが特定の目的に適しているかどうかを測定するのに役立ちます。ここでの前提は、テスト自体が、条件に応じて実際に失敗するように記述されていることです。 （ユニットテストを発見した回数はわかりませんが、ユニットテストは単にデバッガを起動する方法であり、アサーションがなかったためです）
- BDD（Behavior Driven Development）：コードがこれらの要件を確実に満たすように装備できる仕様を作成します。通常、ユーザーインターフェイス自体から使用されます。
これらのツールはコードのさまざまな側面を改善助けることができますが、単純に評価できないことがいくつかあります。これらは、コードの品質にも直接影響します。
- コードで使用される名前の適合性（つまり、メソッド、変数、クラス名）
- 概念の一貫性の評価（つまり、単一責任主体など）
- 正確性のテストの適合性
- 問題を解決するためのアルゴリズムの適合性
- 概念の一貫性
品質を定量的に測定する機能に懐疑的です。しかし、そうする試みは、品質の側面を測定するための優れたツールを提供してくれました。そのため、コードを見て人間が質問できるようにする必要があります。
メーターのような品質スコアを使用することをお勧めします。メーターは、動作基準にあるかどうかを示すだけであり、時間の経過とともにそれらの値を見ると、傾向を示すことができます。彼らが規範の外にいるとき、あなたは調査される必要がある何かがあることを知っています。さらに、傾向が好ましくない状態に向かっている場合は、コードが行き過ぎる前に修正アクションを実行できます。
これはすべて私には無意味に聞こえます。
さまざまな理由により、開発者は品質よりも配信にほとんど専念している
これはあなたの問題ですが、いくつかの新しいルールに集中したいですか？
開発者は、保守可能なコードを書くのに十分気にしていないか、最も可能性の高いシナリオでは、現時点では、ある種の作業の時点を超えて何かを完了する時間がないと感じています。最初のケースでは何も役に立ちません。 2番目のケースでは、マクロプロセスが原因で、マイクロプロセスがそれを修正することはありません。
それはすべて次の2つに帰着します。
- 有能で思いやりのある積極的な開発者
- 管理レベルでの合理的な期待
これらがあれば、残りは自然に続くでしょう。そうしないと、とにかく乾杯します。
私は経営陣と密接に協力しています
良かったので、特別なタスクがコミットされておらず、十分な時間が新機能に起因していることを確認できます。