Pull requestの理想的なサイズとその理由
この記事は、Lancers（ランサーズ） Advent Calendar 2022 の2日目の記事です。
モチベーション
一般的にPull Requestはサイズが小さいほうが良いとされていますが、理想的なPull Requestのサイズは具体的に何行なのでしょうか？
また、なぜPull Requestのサイズは小さい方が望ましいのでしょうか？
本稿ではPull Requestの理想的なサイズとその理由について、リサーチした内容をまとめます。[1]
本稿で取り扱う観点について
Pull Requestのサイズを考察するにあたり、主に注目される観点は以下の2つがあります。
- リーン思考に基づいたフロー効率の観点
- コードレビューに関する観点
本稿では、理想的なPull Requestのサイズについて具体的な数字を示したいというモチベーションから、コードレビューに関する観点について取り扱うことにします[2]。
tl;dr
- 1時間以内に完了するPull Requestのレビューは不具合の発見率が高い
- 200から400行程度のPull Requestは1時間以内にレビューが完了する可能性が高い
- 理想的なPull Requestのサイズは200から400行である
コードレビューをする理由
Pull Requestを用いた開発プロセスでは、殆どの場合コードレビューを行っているかと思います。
では、そもそも何故コードレビューを行うのでしょうか？
IBMの調査によると、コードの欠陥(外部品質、内部品質両方)を発見する最も費用対効果の高い方法がコードレビューだそうです。[3]
レビュー時に検出できた不具合の修正は低コストである
少々本題とは逸れますが、コードレビューの重要性を示す情報についても合わせて紹介します。
不具合の修正は開発プロセスの早い段階であるほど低コストであるというレポートがあります。
7 Principles of Testing - Part 2より
QAエンジニアによるテストプロセスで不具合が検出されるよりも、コードレビュー時に不具合が検出されたほうが修正コストが低い、という考え方ができると思います。
1時間以上かかるコードレビューは低品質
ここまでの内容から、より多くの不具合を検出できるコードレビューが効果的なコードレビューであると考えられます。
Making Software ―エビデンスが変えるソフトウェア開発という書籍の18章「Modern Code Review」では1時間を超えるコードレビューは品質が低下することを示す研究が紹介されています。[4]
加えて、シスコシステムズで行われた調査によると、1時間に500LOC(Line of Code)を超える速度でレビューを行うと、不具合の検出効率が低下することが分かったと報告しています。
以上から、1時間以上かかるコードレビューは不具合の検出という観点において、品質が低下すると言えます。
コードレビューが1時間以内に完了するPull Requestのサイズは200から400行
では、コードレビューが1時間以内に完了するPull Requestのサイズは具体的に何行なのでしょうか？
ある企業でコードレビューにかかる時間と行数を調査したところ、200行程度のPRであれば、90%の確立で1時間以内に完了することが分かったと報告しています。
Optimal pull request size #How much code can my team review in an hour? - Small Business Programmingより
同様に、シスコシステムズで行われた調査から400行を超える行数の変更を一度にレビューしようとすると欠陥を見つける検知能力が下がるという報告があります。
Best Practices for Code Review #Review fewer than 400 lines of code at a time | SmartBearより
まとめ
本稿ではPull Requestのサイズが小さいことが良いとされる理由についてコードレビューの品質の観点からリサーチを行い、内容をまとめました。
結論としては以下のことが分かりました。
- 1時間以内に完了するPull Requestのレビューは不具合の発見率が高い
- 200から400行程度のPull Requestは1時間以内にレビューが完了する可能性が高い
- 理想的なPull Requestのサイズは200から400行である
このことは見方を変えると、Pull Requestの作成者は変更行数に気を配ることによって、レビュアの仕事の質を向上させることに寄与できるとも言えます。
Pull Requestを小さくする方法
最後にPull Requestを小さくする方法についても簡単ですが触れておきます。
- 複数の機能を実装しない
- 1つの機能で実装が大きくなる場合はFeature Toggleを使う
- ついでのリファクタリングをしない
- してもいいけどcherry-pickして別PRをたてるなど工夫しよう
- 本当にそのPRは分割できないか、よく自問自答する
明日はフロントエンドエンジニアの@high_gさんです。
Discussion