プルリクエストレビューは欠陥の15〜30%を検出する。データは50年前からそう言っている。
IBM、AT&T、HP、Microsoftを対象とした複数の研究により、非公式なコードレビューが欠陥の約4分の1を検出することが確認されている。データが実際に示していること、その数値が低い理由、そして改善方法を解説する。
非公式なコードレビューは、レビュー対象コードに存在する欠陥の15〜30%を検出する。これは意見ではない。40年以上、複数の企業、数十の研究を通じて再現された知見だ。…
code-review
7 posts
汎用的なチェックリストは何も見つけられない。構造化されたチェックリストは欠陥の60%を発見する。
大半のレビューチェックリストは、善意のコピペリストに過ぎない。Fagan inspectionスタイルの構造化チェックリストは、実際の欠陥データから構築され、特定のアーティファクトタイプを対象とし、個人の準備段階で使用される。機能するチェックリストの構築方法は以下の通りだ。
チームにコードレビューのチェックリストがあるなら、誰も開かないWikiページに埋もれている可能性が高い。おそらく「check for off-by-one errors」や「verify error handling」といった内容が書かれている。これらは真実だ。しかし、行動を変えるにはあまりにも曖昧すぎる。…
大規模言語モデルはコードの事前査読はできる。会議を運営できない。
フェイガン査読は250行をレビューするのに4〜6人と2時間を要する。大規模言語モデルは準備作業とチェックリストの遵守を担うことでそのコストを削減できるが、最も高価な欠陥を見つける人間の役割は代替できない。
本格的なフェイガン査読には、進行役、読み手、2〜4人の査読者、そして著者が必要だ。チームは1時間あたり125行のペースで、おおむね250行のコードを2時間かけてレビューする。小さな変更でも、8〜12人時の工数がかかるのだ。…
Fagan Inspectionsはテスト前に90%の欠陥を発見していた。それなのに我々はやめてしまった。
IBMでMichael Faganが開発した構造化レビュー・プロセスは、コードがコンパイラに到達する前にほぼすべての欠陥を捉えていた。しかし、その代償として総プロジェクト工数の15〜20%を消費していた。ソフトウェア史上もっとも効果的だったこのレビュー手法がなぜ消えたのか、そしてチームが実際に失ったものは何か。
1976年、Michael FaganはIBM Systems Journalに論文を発表した。そこに記されたレビュー・プロセスは、ソフトウェア品質のゴールドスタンダードとなるほど効果的だった。Fagan…
あなたの最高のレビュアーでも、ほとんどの欠陥を見逃している。Fagan は1976年にIBMでそれを測定した。
シニアエンジニアであっても、非構造化のレビューで欠陥のごく一部しか検出できない。Michael Fagan のIBMにおける研究がその理由を示し、構造化されたインスペクションプロセスを構築して修正した。
二人のシニアエンジニアが同じプルリクエストをレビューする。片方が欠落している null チェックを指摘する。もう片方がクリーンアップパスでの競合状態を発見する。どちらも両方を見つけられない。…
ほとんどのコードレビューは欠陥の20%しか見つけられない。Fagan Inspectionは90%を見つける。
非公式なコードレビューは欠陥の15〜30%を見つける。50年前に確立された構造化プロセスであるFagan Inspectionは、一貫して60〜90%の除去率を報告している。その仕組み、チームが避ける理由、そして軽量版の実行方法を解説する。
ほとんどのコードレビューは、本来見つけるべき欠陥の15〜30%しか捉えられない。これは憶測ではない。IBMが1970年代に測定し、AT&T、HP、Microsoftでの研究が何十年にもわたって同じ範囲を確認している。…
AI時代、コードレビューは仕様レビューになる
AI が仕様から実装、テスト、contracts まで生成できるようになると、人間が最も大きなレバレッジを発揮する仕事は上流へ移る。最も厳しく吟味すべきものは、仕様そのものだ。
AI と一緒に数週間でもリリースを回していれば、この感覚にはもう覚えがあるはずです。 PR を開く。コードは十分きれいだ。命名も悪くない。テストもある。見た目には明らかな破綻はない。なのに、どこかがおかしい。 境界が少し曖昧なのかもしれない。contract…