1600行を1回で出すと、含まれる欠陥24.00件のうち18.92件を見逃しました。
同じ1600行を4回に分けると、見逃しは3.63件です。合計の行数も欠陥の数も同じです。
見る側の集中力には上限があります。上限を超えた行は、読んでいても指摘が落ちます。
AIコードレビューを入れても、1回に渡す量で結果が変わります。実際に計算しました。
100行あたり1.5件の欠陥が入るものとし、丁寧に読めるのは400行までと置きました。それを超えると1行あたりの注意が薄まります。
1回の行数 含まれる欠陥 1行あたりの注意 見つけた欠陥 見逃し 見逃し率 50行 0.76件 1.00 0.65件 0.11件 14.7% 100行 1.51件 1.00 1.27件 0.23件 15.4% 200行 3.00件 1.00 2.55件 0.45件 15.0% 400行 6.00件 1.00 5.10件 0.90件 15.0% 800行 12.00件 0.50 5.13件 6.87件 57.2% 1600行 24.00件 0.25 5.08件 18.92件 78.8%
400行までは、見逃し率が15%前後で一定です。行数が増えても、見つける件数が比例して増えています。
800行を超えると様子が変わります。見つけた件数が5.13件で頭打ちになり、見逃しだけが増えます。
1600行では24.00件のうち5.08件しか見つかりません。400行のときの5.10件とほぼ同じです。
つまり、上限を超えて渡した行は指摘の量に貢献していません。見逃しだけが積み上がります。
出典もこの現象を大きな変更では、詳細な指摘が大量に行き来することで見る側も書く側も疲れてしまい、重要な指摘が見落とされたり流れたりすることさえあるとしています。
上限を超えた行は、指摘の量を増やさない。
With large changes, reviewers and authors tend to get frustrated by large volumes of detailed commentary shifting back and forth—sometimes to the point where important points get missed or dropped.原文Google Engineering Practices「Small CLs」 この内容の有効期限2027-02-18
分割が効くのは上限を超えているあいだだけです。下回れば、そこから先は改善しません。
AIコードレビューで分ければよいと言われますが、どこまで効くのかを測りました。
合計1600行を、1回から16回まで分けて出します。合計の行数も欠陥の数も同じで、変わるのは1回の大きさと回数だけです。
分け方 1回の行数 見つけた欠陥 見逃し 見逃し率 レビューの回数 1回に分ける 1600行 5.08件 18.92件 78.8% 1回 2回に分ける 800行 10.22件 13.78件 57.4% 2回 4回に分ける 400行 20.37件 3.63件 15.1% 4回 8回に分ける 200行 20.38件 3.62件 15.1% 8回 16回に分ける 100行 20.42件 3.62件 15.1% 16回
1回で出すと見逃しは18.92件です。4回に分けると3.63件まで落ちます。
そこから先は動きません。8回でも16回でも15.1%のままです。
4回に分けると1回が400行になります。丁寧に読める上限とちょうど同じです。
上限を下回ってからは、1行あたりの注意が変わりません。分ける手間だけが増えます。
16回に分ければレビューは16回です。出典も回数の目安をこれらの指針に従えば、典型的な変更は必要に応じて1日のうちに複数回の確認を受けられるとしています。
つまり狙うのは上限を下回る最小の回数です。この計測なら4回で足ります。
上限を下回った時点で、分割の効き目は止まる。
Following these guidelines means that a typical CL should get multiple rounds of review (if needed) within a single day.原文Google Engineering Practices「Speed of Code Reviews」 この内容の有効期限2027-02-18
AIは待たせません。読める量の上限が上がるだけで、上限そのものは消えません。
AIコードレビューの利点は速さです。人の確認は、返るまでに時間がかかります。
出典も目安をコードの確認依頼への応答にかけてよい時間は、最大で1営業日である。つまり翌朝いちばんということとしています。
AIなら数分です。この待ち時間の差が、いちばん分かりやすい違いになります。
1番目と2番目はAIに向きます。3番目と4番目は、背景を知っている人でないと判断できません。
AIに読ませれば、1回に渡せる量は増えます。それでも上限はあります。
この計測の形でいえば、400行という値が変わるだけです。上限を超えたときの落ち方は同じです。
だから測るべきは、自分たちの上限がどこかです。行数と、指摘された件数を並べれば見えます。
変更を小さく保つ手そのものはGitの記事で扱っています。分岐を短く保つと、変更も自然に小さくなります。
速さは上がるが、読める量の上限は残る。
「丁寧に読めるのは400行まで」という上限も、1行あたりの見つける確率が0.85という値も、置いた前提です。実際の上限は言語や変更の性質で変わり、AIに読ませれば上がります。欠陥の入り方も一様としています。ここで見せているのは、上限を超えた行が指摘の量を増やさないという関係と、上限を下回ってからは分割が効かなくなるという点です。
One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning).原文Google Engineering Practices「Speed of Code Reviews」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る