111. 小さいPR — 差分が小さいほどレビューは速く深くなる

PR の価値を大きく左右するのが差分の大きさです。数十行の PR は数分で読めて細部まで指摘できますが、数千行の PR は読むだけで疲れ、レビューは「ざっと見て承認」になりがちです。差分が小さいほどレビューは速く、深くなる。これが小さい PR が推奨される最大の理由です。

実務では、1つの機能を複数の PR に刻むのが定石です。たとえば「一覧画面の追加」なら、API 呼び出しのサービス層 → 画面の骨組み → 検索機能、のように段階に分けて順に出します。各 PR が単体でマージ可能な小さな完成品になっていれば、チームのレビュー待ち時間も短くなります。

特に避けたいのが、リファクタリングと機能追加を同じ PR に混ぜることです。名前変更やファイル移動の差分に本質的な変更が埋もれ、レビュアーはどこを注意して読めばよいか分からなくなります。「片付けの PR」と「新機能の PR」は必ず分ける、と覚えておきましょう。

サンプルコード(フレームワーク環境が必要なため表示のみ)

# ── 大きな機能を複数の PR に刻む例 ──
# 「ユーザー一覧画面の追加」を3つの PR に分ける

# PR 1: API を呼び出すサービス層だけを追加
#   user-api.service.ts と、そのテストのみ。画面はまだない

# PR 2: 一覧画面の骨組みを追加
#   user-list コンポーネント。PR 1 のサービスを使って表示するだけ

# PR 3: 検索・並び替え機能を追加
#   PR 2 の画面に検索ボックスを足す

# それぞれが「単体でマージできる小さな完成品」になっているのがポイント

# 自分の PR の差分量はマージ先との比較で確認できる
git diff --stat main
# => 5 files changed, 120 insertions(+), 8 deletions(-)
#    目安: 変更行数が数百行を超えたら分割を検討する

サンプルコードで身につける(5本) →

学んだ概念を、素朴な例から実務寄りの例まで5つの具体例で確認します。

公式ドキュメントで詳しく ↗