レビュアーにやさしいリファクタリングPRを作る

リファクタリングの PR、見るのツラい内容になりがち PR(PullReqeust)を作成してレビューを受け、Approve を受けたらマージする..という開発スタイルはよくあるパターンで、新たな機能追加や修正では観点が明確で動作確認も実施しやすいのですが、これがリファクタリングがテーマになると、途端にレビューが大変になることがあります。 個人的な経験則もありますが、何も意識せずに PR を作ると、次のような問題が発生しやすいように感じます。 １テーマに関する修正が一気に詰め込まれていて物量が多い 何を確認したらよいのかわからない 複数 PR に分けている場合に、後続の PR だけを見ても理解できない など... リファクタリングの PR は内容も淡々としたものになることが多く、確認もリグレッションテストが中心で、レビュアーはそこそこ心を削られます。そのうえ上記のような問題を抱えていると、

[nharuki]

ちょーだいじ → "途中で見つけた他の改善点をすぐに全部拾おうとしない"

[h5y1m141]

似た感じで書いてる！不安点や特に見てほしい部分についてはPR作成時に該当箇所のコードに自分でコメントしてからレビュー依頼するようにしてる。あと途中で見つけた他の改善点はコメントよりIssue作るのが好み

[guitgraph]

]

[d14a]

よい

[phoope]

わかった

[yimajo]

“途中で見つけた他の改善点をすぐに全部拾おうとしない”

[Shisama]

めっちゃ良い。これまで感覚でやっていたことからなるほどと思えることまでわかりやすい説明で書かれている。「PRの小ささを保てる範囲内で、PRの外で確認しないといけない情報を減らす」はPR分割の良い指針と感じた