コードレビュープロセスの有効性を判断する方法

組織内にコードレビュープロセスを導入しましたが、うまく機能しているようです。しかし、時間の経過とともにプロセスの有効性を測定できるようにしたいと思います。つまり、コードがクリーンであるためにバグを見つけられないのですか、それとも人々がバグを拾っていないのでしょうか。

現在、効果的な完全自動化されたテストプロセスはありません。私たちは主に手動テストを採用しているため、この段階で見つかった欠陥に頼ってコードレビュープロセスが機能していることを確認することはできません。

誰もこの問題に出くわしたことがありますか、コードレビューの測定で何がうまくいくのかについて考えたことはありますか？

コードレビューから収集できるメトリックは多数あり、プロジェクトのライフサイクル全体に及ぶメトリックもあります。

収集することをお勧めする最初のメトリックは、欠陥除去の有効性（DRE）です。欠陥ごとに、欠陥が導入されたフェーズと除去されたフェーズを特定します。使用するさまざまな欠陥検出技術はすべて同時に評価されるため、要件レビュー、設計レビュー、コードレビュー、単体テストに等しく適用されます、 等々。これはおそらく、コードレビューだけでなくユニットテストも含まれるため、コードフェーズで検出された欠陥の数に特に興味があります。コードフェーズからの多くの欠陥が統合テストフェーズまたはフィールドにまで及んでいる場合、ポストコーディングプラクティスを評価する必要があることがわかります。

さまざまな会議の測定基準も関連します。これらには、準備する時間、会議の時間、コードの読み取り行、レビューで見つかった欠陥などが含まれます。このデータからいくつかの観察を行うことができます。一例として、レビュー担当者がレビューの準備のためにコードを読むのに多大な時間を費やしているが、問題をほとんど見つけていない場合があります。DREデータと組み合わせると、統合テストまたはフィールドで欠陥がテストされている場合、チームは問題を見つけるためにレビュー手法に集中する必要があるという結論を導き出すことができます。もう1つの興味深いメモは、会議の時間と比較して会議で読み取られるコード行（またはその他のサイズ測定値）です。調査の結果、典型的なコードレビューの速度は1時間あたり150行のコードであることがわかりました。

これらのメトリックのいずれかを使用して、プロセスへの影響を理解することが重要です。why-because、Five Whys、またはIshikawaダイアグラムなどの手法を使用した根本原因分析を使用して、コードレビュー（またはその他の品質改善手法）が（無効）効果がある理由を特定できます。

また、The Ganssle Groupからの検査に関するこの記事と、欠陥ポテンシャルとDREに関するクロストークのCapers Jonesの記事にも興味があるかもしれません。

主に、コードレビューが、テストがキャッチする場合もキャッチしない場合もある潜在的な問題を拾い上げることは事実です。しかし、私の意見では、あなたは本当に安定した（事実上バグのない）コードを持っているかもしれませんが、それでも非常に読めないか、まったくメンテナンスできないような方法で書かれています。そのため、実際にコードに問題がなければ、コードレビューではバグが見つからない可能性があります。

そうは言っても、なぜコードレビューをしたいのでしょうか？それが重要である単純な理由は、コードをより読みやすく、保守しやすく、進化可能にするために改善する必要があるということです。多くの人は、よりクリーンなコードを読み、それを理解できるはずです。その意味で、コードレビュープロセスの最も単純な目的は、クリーンなコードを生成することです。したがって、有効性の尺度は、コードがどれだけきれいになったかです。

あなたが測定可能な有効性を持ちたかったので、ここに私が提案するものがあります：

1. リワークの量に関連するメトリック-同じ特定のモジュール/オブジェクト/ワークアイテムにリワークが適用される回数は、そのコードが保守性の面でどれだけ貧弱であるかの尺度です。効果的なコードレビューが適用された場合、同じモジュールでの再作業リクエストをどれくらいの頻度で減らすことができますか？

2. すべての変更要求が被る変更の量に関連するメトリック。変更要求が発生するたびに- 因数分解が不十分なコードでは、常により多くのモジュールが影響を受けます。おそらく、コードレビューの後、過去の同様の変更要求に対するこのような変更の広がりが減少したということでしょうか？

3. 変更要求に応答できる平均速度に関連するメトリック。コードがきれいになったら、必要な変更に対応するのが速くて良いです。レビュープロセスでコードがクリーンアップされた後、同様のサイズのリクエストへの応答がスピードアップします。

正確な測定単位を入れているわけではありません。おそらく、このアプローチからこれについてより正確な測定値を作成できます。これに関する上記のアプローチには、より多くの拡張形式があります。

基本的に、私のポイントは、コードレビュープロセスが特定するバグの数ではなく、コードレビューにより、コードをよりクリーンで無駄のない、維持しやすい状態にすることができたかどうかの観点から有効性を測定する必要があります。したがって、将来同様の変更要求がより効率的に応答されるようになった場合、その有効性を評価できます。