GitHub Flow ベースの開発においてはあまり大きな pull request を作ってほしくないという話。
なんというか今更わざわざ言わなくてもいいんだけど…

仕事で何度か大きな pull request が投げられているのを見てしまったので、それはあまりよくないよというのを自分でも指摘しやすくするためにまとめておく。

Reference

最初に参考資料を挙げておく。

これらを読めば特に私から言うこともないのだが…
これらに書いてあるとおりだが補足しておく。

Pull Request を小分けにしたときのメリット

module を適切に切り出すモチベーションが得られる

次のような話がある。

これを理由に module を分けるべきところが分けられず、いろんなことができてしまうベタッと大きな module が生まれるのを見た。

もちろんよく考えられていない共通化は駄目だが、上記ポストでは一方で

ただし共通化という名の下におこなわれるのは「同じロジックを持つコードをまとめる」行為であって、抽象化のようにそのコード単位の意味を捉える作業はその範疇にない。抽象化というのはロジックを意味単位ごとにひとくくりにしていく行為で、これがどういうことなのかは次以降で述べていく。
– 共通化という考え方はアンチパターンを生み出すだけ説 - タオルケット体操

と述べており抽象化、つまりコードの意味を考慮した上で適切な単位でまとめておくことは否定していない。

pull request を小さく分けるという行為のためには module や機能を適度なまとまりで切り分けること、つまり抽象化を考えていくことが必要となる。
したがって何でもできてしまう大きな module が生まれるのを防ぐ方向に働く。
(もちろんここで駄目な共通化がなされてしまうこともあるだろう)

リリースまでの期間が短く済む

前述の参考資料においても pull request が大きいと

Developers would put off reviews until they had time/energy and the development process would come to a halt.
– 100 Duck-Sized Pull Requests

development continues on the master branch, it often results in merge conflicts, rebases, and other fun.
– 100 Duck-Sized Pull Requests

となると述べられている。
仮にすぐにレビューされ、かつ conflict なども発生しなかっとしても大きな1つの pull request をレビューする場合とそれを3つに分けた場合の開発プロセスの進行を比較すると

  • 大きな1つの pull request
    1. 全体の開発
    2. 全体のレビュー
  • 3つに分割された pull request
    1. part-1 の開発
    2. part-1 のレビュー & part-2 の開発
    3. part-2 のレビュー & part-3 の開発
    4. part-3 のレビュー

のようになり、開発とレビューを並列で進められる部分があるので全体としての開発期間を短くすることができる。
もちろんこれはうまく噛み合ったときの例だが。
早めにフィードバックが得られるのも大きい。

Pull Request を小分けにしたときのデメリット

小分けにすることでレビュワーが全体感をつかみにくくなるというのはあるかもしれない。
part-1 と part-2 で同じレビュワーになるとも限らない。

これに対しては開発に着手する前にまず全体のざっくりとした設計についてレビューを受けることで対応できる。
このステップを入れることで「とりあえず手を動かそう」となりにくくなる。
手を動かすと仕事してる感が出るのでとりあえず手を動かしたくなりがちだが、ちょっと待てよと。
まず何を作るか、全体の工程を考えましょうと。

Working under these constraints causes developers to break problems down into incremental deliverables. It helps avoid the temptation of jumping into development without a clear plan.
– 100 Duck-Sized Pull Requests

まとめ

pull request を分けてくれ、頼む。