コードレビュープロセスの有効性を判断する方法
組織内にコードレビュープロセスを導入しましたが、うまく機能しているようです。しかし、時間の経過とともにプロセスの有効性を測定できるようにしたいと思います。つまり、コードがクリーンであるためにバグが見つからないのですか、それとも人々がバグを拾っていないのですか？
現在、効果的な完全自動化されたテストプロセスはありません。私たちは主に手動テストを採用しているため、この段階で見つかった欠陥に頼ってコードレビュープロセスが機能していることを確認することはできません。
誰かが以前にこの問題に遭遇したことはありますか、またはコードレビューの測定で何がうまく機能するかについて考えたことはありますか？
コードレビューから収集できるいくつかの指標があり、プロジェクトのライフサイクル全体に及ぶものもあります。
収集することをお勧めする最初のメトリックは 欠陥除去効果（DRE） です。すべての欠陥について、欠陥が導入されたフェーズと除去されたフェーズを特定します。使用するさまざまな欠陥検出手法はすべて同時に評価されるため、要件レビュー、設計レビュー、コードレビュー、単体テストに等しく適用されます、 等々。コードフェーズで検出された欠陥の数に特に関心があります。これはおそらくユニットテストとコードレビューを網羅するためです。コードフェーズからの多くの欠陥が統合テストフェーズまたはフィールドにまで及んでいる場合、ポストコーディングプラクティスを評価する必要があることがわかります。
さまざまな会議の指標も関連します。これには、準備する時間、会議の時間、読み取ったコード行、レビューで見つかった欠陥などが含まれます。このデータからいくつかの観察を行うことができます。一例として、レビュー担当者がレビューの準備のためにコードを読むのに長い時間を費やしているが、問題がほとんど見つからない場合が考えられます。 DREデータと組み合わせると、統合テストまたはフィールドで欠陥がテストされている場合、チームは問題を見つけることができるようにレビュー技術に集中する必要があるという結論を引き出すことができます。もう1つの興味深いメモは、会議の時間と比較して会議で読み取られるコード行（または他のサイズ測定）です。調査によると、一般的なコードレビューの速度は1時間あたり150行のコードです。
これらのメトリックのいずれかを使用して、プロセスへの影響を理解することが重要です。 why-because 、 Five Whys 、または Ishikawa diagram などの手法を使用した根本原因分析を使用して、コードレビューの理由を特定できます（またはその他の品質改善手法）は（効果がありません）。
The Ganssle Groupからの検査に関するこの記事 および 欠陥の可能性とDREに関するクロストークのCapers Jonesによる記事 にも興味があるかもしれません。
code reviewは、テストがキャッチするかもしれないし、しないかもしれない、かなり潜在的な問題を拾うことは大抵事実です。ただし、私の意見では、非常に安定した（実質的にバグのない）コードを使用しているにもかかわらず、非常に読みにくいか、または保守しにくいコードで書かれている可能性があります。そのため、コードレビューで実際にコードに実際の問題がない場合は[〜＃〜] not [〜＃〜]バグを見つける可能性があります。
そうは言っても、私は本当に尋ねます、なぜコードレビューをしたいのですか？それが重要である単純な理由は、コードをより読みやすく、保守しやすく、進化可能にするために改善する必要があることです。多くの人がよりクリーンなコードを読み、それから意味をなすことができるはずです。その意味で、コードレビュープロセスの最も単純な目的は、クリーンなコードを生成することです。したがって、有効性の尺度は、コードがどれだけクリーンであるかです。
あなたが測定可能な有効性を持ちたかったので、ここに私が提案するものがあります：
リワークの量に関連するメトリック-同じ特定のモジュール/オブジェクト/ワークアイテムにリワークが適用される回数は、poorのコードの保守性の尺度です。効果的なコードレビューが適用される場合、同じモジュールでの再作業リクエストを削減できる頻度はどれくらいですか？
すべての変更リクエストで発生する変更の量に関連する指標。変更要求が発生するたびに-悪い因数分解されたコードは常に影響を受けるモジュールの数が多くなります。メジャーはおそらく、コードレビューの後に、過去の同様の変更要求に対するそのようなspread変更の削減があったことを示しているでしょうか？
変更要求に応答できる平均速度に関連するメトリック。コードがよりクリーンな場合-必要な変更に対応することがより速く、より優れています。レビュープロセスでコードがクリーンアップされた後、同様のサイズのリクエストへの応答が高速化されたことがわかりました。
正確な測定単位は指定していません。このアプローチから、これについてより正確な測定を作成できます。これに関する上記のアプローチには、より多くの拡張形式がある可能性があります。
基本的に、私の見解は、コードレビュープロセスで特定されたバグの数ではなく、コードレビューがコードをよりクリーンで無駄のない、メンテナンスしやすい状態にすることができたかどうかの観点から、有効性を測定する必要があります。したがって、将来的に同様の変更要求への対応がより効率的になることがわかった場合、その有効性を測定できます。