概要
PRの分割は一般的に「レビュワーの負担を下げて、マージのスピードを上げる」ために行われると考えられています。しかし、それは表面的なメリットに過ぎません。
本書では「なぜPRの分割によりレビュワーの負担が下がるのか。なぜスピードが上がるのか。」から出発し、本質的なメリットに迫ります。そして、1PRにつきユーザー視点のひとつの関心ごとを扱うこと、PR同士の依存関係・順序を整理すること、といった具体的な分割の方法を解説します。
さらに、分割のメリットだけでなく、CI/CDコストの増加や直列依存によるコンフリクトといったデメリットまで網羅的に紹介し、それらに対して実装者・レビュワーが運用上意識するべきことまで扱います。
「どの単位で分割するか」を考えること自体が「ユーザーへ提供したい価値」への理解と直結している、というのが本書の一番伝えたいメッセージです。
なお、レビュワーとは他人だけでなく自分自身でもありえます。そのため、レビューを必須としない個人開発やAI活用が進んだ現場でも通用する内容を目指しています。
対象読者
主にGitHubを利用したチーム開発をしているエンジニアです。「PRが大きいので分割してください」と言われて面倒に感じたことのある方に、特に読んでいただきたい一冊です。
目次
- まえがき
- はじめに
- 私とGitHubとの出会い
- 初めてのPull Request作成 / レビュー
- Pull Requestを分割する表面的なメリット
- Pull Requestを分割する本質的なメリット
- 分割できるかどうかが、理解度の深さを示す
- 本書について
- 1章 Pull Requestとは何か
- Pull Requestの定義
- PRはコード差分の価値を伝えるためにある
- 価値が伝わるPRと伝わらないPR
- PRの単位は「伝えたい価値」で決まる
- 2章 どのように分割するか
- デプロイ順序に技術的依存関係のある変更を分割する
- 1PRにつき「ひとつの関心ごと」を扱う
- 関心ごとによる依存関係・順序を整理する
- 3章 分割するメリット
- 自分の理解が深まる
- 実装漏れが可視化される
- 小さい単位で早く動作確認ができ、QA精度も上がる
- レビュワーが集中してレビューできる
- たくさんマージできてテンションが上がる
- 理論上のリリースまでの合計時間が短くなるケースがある
- 4章 分割するデメリット
- 分割しすぎるとオーバーヘッドが増える
- 全体感が見えにくくなる
- 直列依存のPRでは、変更が波及しやすい
- 5章 PRの分割を運用するために実装者とレビュワーが意識するべきこと
- 適切な粒度を見極める
- 最初に全体感を合わせておく
- PRはとにかく早くレビューし、早くマージする
- さいごに