参考

 まとめ
 1つのことだけに注力する作成するPRが1つのことだけを行なっているかどうかで変更行数・ファイル数は関係ない

(粒度が大きすぎるとレビューの負荷が高まり品質の低下につながるため)
粒度の目安として、
revert単位として適切か
レビュワーのコンテキストスイッチは最小限に収まっているか
複数の対応を一度に入れ込んでないか
ユーザーから見えない変更は一気に行う必要がないことが多い
以下の場合、粒度が適切なのは前者
特定の関数名を一括置換して1万行変更
画面開発とリファクタで20行変更
そのためにタスク分解が必要になる

 タスク分解マークダウンのチェックボックスでOK

大枠から分解していくことを意識して作成する

小さい機能追加を何回も繰り返して結果的に大きな機能を完成させるイメージを持つ

この時メンバーのレビューも入れると意識が揃って良い

途中でさらに分解するのもOK

 目安は200-400行200−400行は1時間以内にレビューが完了できるレベル

1時間以内に完了するレビューは不具合の発見率が高い

seiya2130

ファイル・クラス・関数・変数の追加系は追加だけのPRを作る(後続の変更が巨大なら尚更)

seiya2130

当初の設計・修正箇所を確認してPRが巨大になりそうならリファクタから始める
着手の段階で変更を分割して適用できないか、どんな設計だといいのか考える

seiya2130

PRを分割する場合は、変更ごとに開発ブランチを作成してマージしていく
ただしマージ先ブランチのレビューが済んでからマージしていく

(例)feat2がレビュー前・レビュー中なのにfeat3をマージしてしまうと、feat3の変更がfeat2にマージされPRを分割して変更差分を小さくした意味がなくなる