Pull Request まわりの考察
■ 付記 注意点として、高い成熟度を目指すことが必ずしも望ましいとは限らない。 高い成熟度を目指すには、以下が必要になると思われる； lint といった静的解析をするツールや、テストを実行するツール リポジトリに関するドキュメントや、それを保守するフロー PR を作成するレビュイの／PR を読むレビュワの時間・体力 低い成熟度のレビューでも構わないのならば、PR を作成する／読む時間・体力は、比較的小さいものになるであろう PR を適度な粒度で作成することは、レビューの成熟度の高さに寄与するであろう（この詳説は次の節に譲る） PR を適度な粒度で作成しないと、チームとして目指せる現実的なレビューの成熟度の限界は 3, よくて 4 程度であるように感じる 詳細な要求仕様と、それを管理するためのツール これはトレードオフとも解釈でき、チームとしてレビューにどこまでを求めるかという判断でもある。
Pull Requestを分割する技術 〜レビューで疲弊しない/させないために〜 - Qiita
何故 Pull Request(以下、PR) を分割するのか？ レビュアーを疲弊させないため 自分が疲弊しないため レビューの精度/速度を上げるため PRを分割しないと、何が起きるのか 時折、それなりに規模の大きな機能を実装する必要がでてきたり、当初はそこまででもないと思っていたが、いざ実装し始めてみたら色々必要になり、結果大規模な作業内容になった、というケースが出てくる。 そうした状況で、諸々の作業内容をまとめて一つのPRとして作成すると、一旦どんな問題が起こるか。 以下、レビュアー/レビュイーの視点からまとめてみる。 レビュアーの視点から 1. 追加/変更ファイル数が多い 単純に圧倒される ファイル変更に伴う依存関係のチェックが大変 どこからどこまで変更が入ったのか、影響範囲がどの程度か、把握が大変 2. diffの量が数百行有って辛い 単純に死ぬほど見づらい diffが多いと目が滑る
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
