コードレビューに適用されたシグナル対ノイズ比とは、プルリクエストについたレビューコメントのうち、対応する価値のある事柄を提起しているものの割合である。これは、重大なシグナルまたは重要なシグナルを含むコメントの数をコメントの総数で割って算出され、何一つ対応すべきものがなかった 0.0 から、すべてが対応すべきものだった 1.0 までの値をとる。その目的は、レビュアーがどれだけ多くを語ったかと、そのうちどれだけが重要だったかを切り分けることにある — この区別は、レビュアーが自動化され、コメントをもう 1 つ生成するコストがほぼゼロにまで下がると重要になる。
用法
この指標には、どのコメントをシグナルとして数えるかを決めるルールが必要である。業界の主張から実証的な現実へ：プルリクエストにおけるコードレビューエージェントの実証研究 は、2 段階のキーワード階層によってこれを運用可能にしている。第 1 階層の重大なシグナルは、実行時エラー、クラッシュ、コンパイルの失敗、API の破壊的変更、セキュリティ脆弱性を対象とする。第 2 階層の重要なシグナルは、アーキテクチャ上の問題、パフォーマンスの問題、保守性に関する懸念を対象とする。いずれかの階層に一致するコメントは分子に数えられ、それ以外はすべてノイズとなる。
この研究はまた、得られた比率を、シグナルとノイズのどちらが優勢かを各帯域が示すように選ばれた 4 つの帯域に分けている。0〜30% は主にノイズで、対応すべきコメントが 3 分の 1 未満である。31〜59% はシグナルよりノイズが多い。60〜79% はノイズよりシグナルが多い。80〜100% は主に対応すべきものである。0.60 と 0.80 を、それぞれ良いフィードバックと優れたフィードバックの閾値として扱っている。
コードレビューエージェント によってのみレビューされていた放棄済みのプルリクエスト 98 件にこの指標を適用したところ、その 60.2% が最も低い帯域に入り、関与した 13 のエージェントのうち 12 が平均 60% を下回っていた。同じ分析では、コメントの量とシグナル比率はおおむね独立していることも分かった — 最もスコアの高いプルリクエストについていたコメントはそれぞれ 1〜3 件にすぎなかったのに対し、最もスコアの低いものは 1〜8 件に散らばっていた。
適用される場面
この指標は、ある作業単位に対するレビューコメントの集まりが存在し、各コメントについて問題を提起しているかどうかを個別に判断できる場面に適用される。これは本質的に比較のための指標である。単独の比率だけではほとんど何も分からず、実際には、あるレビュアー、あるいはある種類のレビュアーを別のものと比べるために使われる。
この指標は、対応すべきフィードバックはコメントのテキストから見分けられること、そしてコメントが数えるべき正しい単位であること — 問題を提起する 2 つのコメントは 1 つのコメントの 2 倍のシグナルであること — を前提としている。また、分類ルールが、そのコードベースのレビュアーが実際に対応する価値があると考えるものと一致していることも前提としているが、上記のキーワード階層はそれをプロジェクトから導き出すのではなく、あらかじめ固定している。
この指標が破綻するのは分類ルールにおいてである。これを適用した著者たち自身が妥当性への脅威の中で、キーワード照合では、どのキーワードも含まない言い回しの対応すべきフィードバックを見逃しうること、そしてキーワードを含むが無関係なコメントをシグナルとして数えうることを述べている。彼らは、不一致を議論してキーワードリストを改良した 2 人の独立した評価者による手作業の検証でこれを緩和し、評価者間一致度について Cohen の Kappa 0.75 に達したと報告している — これは、その手作業のステップ自体が判断を取り除くチェックではなく、判断を伴うものであることを記録している。この指標が招くさらなる誤読は、ごく少数のコメントから得られた高い比率を、多数のコメントから得られたものと同等に扱うことである。その研究で 100% を記録した唯一のエージェントは、1 件のプルリクエストしかレビューしていなかった。
この指標は確立された標準ではない。上記の研究は、引用しているブログ記事からこの枠組みを採用し、2 段階のキーワード階層と分類手順は自ら用意しており、質的手法としてオープンコーディングを用いている。公表されている実績は、その 1 回の適用のみである。
関連用語
- コードレビューエージェント — この指標が主に評価に使われてきた種類のレビュアー