調査結果に基づかなくても体感で分かると思いますが、プルリクエスト(以下PR)のサイズはレビューの効率性と品質に大きな影響を与えます。
PRが小さいほど、レビューが容易で、フィードバックのサイクルが早く、問題の特定と修正が容易になります。
特定のタスクや変更に対応するために、PRを小さく、焦点を絞ったものに保つことが推奨されます。
Pull Request（PR）の適切なサイズについては、いくつかの調査があります。
Cisco SystemsのLOCとの相関
smartbearの調査では、PRの理想的なサイズは400行未満とされています。
この内容は、Cisco Systemsのプログラミングチームを対象としたSmartBearの調査で、開発者は一度に200〜400行のコードのレビューが取りこぼしの上限値であることが明らかになりました。
脳が一度に効果的に処理できる情報は限られています。LOCが400を超えると、欠陥を見つける能力が低下します。
実際は、60〜90分にわたって200〜400個のLOCをレビューすると、70〜90%の欠陥が発見されています。
コードに10個の欠陥が存在する場合、適切に実施されたレビューでは7〜9個が見つかりました。
この調査の数値は、コードレビューに60分〜90分費やしているという前提を抑えている必要があり、日々の業務で数分程度しかレビューしない人には明らかに変更量が大き過ぎます。
一度に60分以上確認しない
1日のコードレビューに60分以上費やす人がどの程度いるかは謎ですが、一度にレビューする時間が長すぎるのはよくありません。
集中した作業が必要な活動に長時間従事すると、約60分後にパフォーマンスが低下し始めます。
研究によると一定期間にわたってタスクを休むことで、仕事の質が大幅に向上することがわかっています。
より頻繁にレビューを実施することで、この長さのレビューを行う必要性が減るはずです。
harnessのLOCとの相関
harnessの調査では、105行以下のPRが最も効果的であると示されています。
一般的に上記のように60分以上もコードレビューをすることは考えいくいので、こちらの方がより現実的だと思います。
PRのレビューエクスペリエンスは、サイズによって大きく異なります。
ここでは、105行のPRと400〜800行のPRのレビューを比較しています。
小さなPR(105 行未満)
良い焦点：レビュアーは変更をより詳細に確認できるため、良いフィードバックが得られます。
多くの共有：PR が小さいということは、コードがより頻繁に共有されることを意味するため、全員が何が起こっているかを把握できます。
時間の節約：レビュアーは各PRに費やす時間が短くなるため、自分の作業を行うこともできます。
大型PR(400-800ライン)
情報処理するには多すぎる：大規模なPRは圧倒され、本来変更に必要な注意を引けない可能性があります。
表面レベルのレビュー：多くの場合、コード変更が大きいPRは、重要な問題を見逃す可能性のある高速チェックが行われます。
チーム・ディスコネクト：PRの頻度が低く、かさばると、チームメンバーは互いの仕事についてあまり知らされず、理解のギャップが生じる可能性が高くなります。
理論的にPRサイズは重要です。
大規模なPRは、物事を遅らせ、チームにストレスを与え、リリースを遅らせ、全員にとって物事を難しくします。
例えるなら、学校で読まざるを得ない大きな本があった時のようなものです。
多くの人は、本全体が多すぎるため要約本を選びます。
小さなPRは注目を集める短い記事のようなもので、大きなPRはざっと目を通すだけの大きな本のようなものです。
軽量なコードレビューを実践する
Cisco SystemsのSmartBearの調査によると、軽量コードレビューにかかる時間は、正式なレビューの20％以下であり、同じくらい多くのバグが見つかることがわかっています。
ヘビーウェイトのレビューでは、200LOCあたり平均9時間かかります。
この厳格なプロセスは効果的であることが多いものの、最大6人の参加者と、詳細なコードのプリントアウトを見ながら何時間も会議を行う必要があります。
SCM Committers Report は、個々の開発者の貢献を評価するのに特に便利です。
開発内容の意図を明確にするために、各コミッターの関与について次のことを意識してみるのも良いでしょう。
- 作業した PR の数
- 作成したコミット数
- 貢献したコードの行数
この情報は、説明責任と透明性を確保し、効果的なプロジェクト管理とリソース割り当てを行い、開発者やチームのパフォーマンスを評価するために役立ちます。
エンジニアリングチームは、まず人材、プロセス、ツールのボトルネックを把握し、継続的な改善プロセスを検討しましょう。
最後に
どのような調査結果でも、PRのサイズはレビューの効率性と品質に大きな影響を与えることがわかります。
PRが小さいほど、レビューが容易で、フィードバックのサイクルが早く、問題の特定と修正が容易になります。
調査や研究に限らず、人間の認知機能の当たり前として、特定のタスクや変更に対応するために、PRを小さく焦点を絞ったものに保つことが推奨されます。
ただし、これらの数字は一般的なガイドラインであり、具体的な数値はプロジェクトの性質やチームの状況により異なります。
最終的に具体的な数値を決めざるを得ない場合、PRのサイズはコードの品質を確保し、効率的なコードレビューを促進するためのものであるべきです。
それを決めるには今現在のPRの計測をする必要がります。SCMレポートなどを使用して、PRアクティビティを測定する所から始めてみましょう。
