Pull Requestを小さくしよう
300行くらい超えてくるあたりから急激に見るのが辛くなってくる
PRの鮮度が落ちる
コンフリクトつらいし
レビュワーが一度読んでも再びreview requestすることになり非効率的
デプロイ後の不具合原因の特定が難しい
小さい意味のある変更があるプルリクをマージしていくことは1つの仕事の指標になりそう。少しでも前に進むので。
ではどうするといいのか
タスクごとにPRにしよう (適切に変更内容を分解する)
webpackの設定, とか .gitignoreに追加, とか migrationファイルの追加, validationの追加 などなどの単位で切ってしまってよい
もちろん開発フェーズによるのでエイヤでやったほうが早いときはそれでやる
完全な新機能実装とか
初期実装で完全にでかいプルリク作ってからあとで分解するという手法してる人がいるぽく、それは良いなと。
既存のコード上に何か追加するときは細かくデプロイできるほうがうれしい
レビュワーもうれしい
10ファイル, 100行diffくらいまでならすぐ見られる(主観)のでそれくらいの粒度で切りたい
なるべく細かくmainブランチにマージ/デプロイできるように実装する
何かの機能を実装するとして、その機能を設定する画面への導線はつくらないとか, 何かしらアクセス制限かけておく
リリース時につなぎこむ
例外(長くなってもいいよねというやつ)
機械的な置き換え
prettier fixやら, 名前の一斉置換やら
diff10000行とかになりうるが中途半端にやってはより辛いものはエイヤで...
https://gyazo.com/7e49726c678c1071bd2e32aae8b38279
とはいえ
やっぱ変更でかくなってしまうのはありますね. その点で静的型付けが欲しいとなることがしばしばある
リンク