エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
Pull Requestを分割する技術 〜レビューで疲弊しない/させないために〜 - Qiita
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
Pull Requestを分割する技術 〜レビューで疲弊しない/させないために〜 - Qiita
何故 Pull Request(以下、PR) を分割するのか? レビュアーを疲弊させないため 自分が疲弊しないため レ... 何故 Pull Request(以下、PR) を分割するのか? レビュアーを疲弊させないため 自分が疲弊しないため レビューの精度/速度を上げるため PRを分割しないと、何が起きるのか 時折、それなりに規模の大きな機能を実装する必要がでてきたり、当初はそこまででもないと思っていたが、いざ実装し始めてみたら色々必要になり、結果大規模な作業内容になった、というケースが出てくる。 そうした状況で、諸々の作業内容をまとめて一つのPRとして作成すると、一旦どんな問題が起こるか。 以下、レビュアー/レビュイーの視点からまとめてみる。 レビュアーの視点から 1. 追加/変更ファイル数が多い 単純に圧倒される ファイル変更に伴う依存関係のチェックが大変 どこからどこまで変更が入ったのか、影響範囲がどの程度か、把握が大変 2. diffの量が数百行有って辛い 単純に死ぬほど見づらい diffが多いと目が滑る