プルリクエストを小さくして、品質とスピードの両立を試みる
ライフイズテック サービス開発部 塾プロダクトグループの山口 (@no_clock) です。ソフトウェアエンジニアをしています。
開発チームのちょっとした改善として、プルリクエストを小さくして品質とスピードの両立を試みている話です。
なぜプルリクエストを小さくするのか
問題は早期発見できたほうが、コストは低い
バグや問題点は早めに気づいたほうが良い、というのは多くの方の共通認識かと思います。書籍「Google のソフトウェアエンジニアリング」でも、「左への移動」として説明があります。
1.2.4 左への移動
（略）
コミット前に静的解析とコードレビューで捕捉されるバグは、本番環境に到達するバグよりずっとコストが低い。
この左への移動を実現する方法の 1 つが、「プルリクエストを小さくする」というやり方です。
プルリクエストを小さくすると、コードレビューで問題に気づきやすくなる
プルリクエストが大きいと、コードレビューも大味になりがちです。 SmartBear の調査では、 1 度にレビューするコードは 400 行未満が良く、 400 行を超えると欠陥が見つかりにくくなるとされています（下図は引用）。
Google Engineering Practices Documentation のコードレビューガイドライン（非公式日本語訳）でも、プルリクエストに相当する CL (Changelist) を小さくする 小さな CL が推奨されています。ガイドラインでは、小さくすることでレビュアーだけでなく実装者自身もバグがないか確認しやすくなるとされています。
- バグが入りにくくなる。 より少ない変更しか加えていないため、あなたもレビュアも CL の影響を効果的に考えやすくなり、バグが入り込んでいないか確認しやすくなります。
開発チームでやってみました
プルリクエストあたり 300 行未満を目安として、約 1 ヶ月半実施しました。
| 項目 | 実施前の 1 ヶ月半 | 実施後の 1 ヶ月半 |
|---|---|---|
| プルリクエストの平均サイズ | 708.7 行 | 198.6 行 |
| プルリクエストの数 | 45 個 | 168 個 |
| コードレビューでのバグ発見数 | 4 件 | 15 件 |
バグ発見数が約 4 倍に増えました 🎉
一方で、プルリクエストのサイズ・数を見ると、開発量はほとんど変わっていません。
「スピードを落とさずに、品質を向上させることができた」と言えそうです。
ほかにもいいこと
プルリクエストを小さくすると、ほかにもいいことがありました。
- スクラム開発のスプリント終盤にコードレビューが集中していたが、平準化した。
- コードレビューが大変でしんどいもの、という気持ちがほぼなくなった。
- クラスや関数の設計について、気軽に議論しやすくなった。
今回はプルリクエスト・コードレビューにフォーカスしましたが、さらに「左への移動」も可能だと思っています。品質とスピードを両立しながら、よりよいプロダクトを届けていきます。
ちょっと宣伝
ライフイズテック サービス開発部では、月ごとに気軽にご参加いただけるカジュアルなイベントを実施しています。開催予定のイベントは、 connpass のグループからご確認ください。興味のあるイベントがありましたら、ぜひ参加登録をお願いいたします。ご参加お待ちしています！
Discussion