前提
- 現在 Web 業界で主流(?)な 100 % PR を完成させてから（マージできる状態にしてから）In Review にするやり方は非効率
- PR はざっくりできた 〜 In Review までがけっこう作業ある（commit 粒度の確認、YARD などのコメント、GitHub の 0 コメ、動作確認手順記載）
- レビュー時に設計レベルのちゃぶ台返しをされた時に時間的無駄や、精神的疲労が蓄積される
- 👆 のしんどさは主にジュニア~メンバークラスの人々が感じることが多く、シニアになると指摘される数が減り修正も早いのであまり危機意識を感じなくなるのではないか（だから自分が考えてみる）
こうした方がよいのではないかという案
- 新機能や広範囲に渡るリファクタリングはモブ設計（クラスやインターフェースの設計）を行い、可能ならばテストまで書く
- 実装は一人に任せてもよいし、新規の外部 API などを叩くのであれば、モブで続けてもよい
- レビューは実装でバグやパフォーマンス的に問題になる部分のみする（N+1、O(n2) など）、基本は動いていれば OK
- 改行などの指摘は linter が通っていればスルーする
- どうしても気になるならばレビュアーが別途 PR を作る or 「どうしても気に入らなかったら revert してください」と commit してしまう
- typo は GitHub の suggestion を使う or 自明ならばレビュアーが commit
- コンフリクトも自明ならばレビュアーが commit しても良い
- どうしても設計レベルの指摘を行う場合は代替の PR もしくはペアプログラミングで修正する
メモ
- どこまでモブでやるかの線引き難しい、どこまでが設計でどこから実装なのかはっきりさせたい（例: 関数名を考えるのは設計か？引数と返り値を考えるのは実装か？）
- 設計部分をモブでやることでジュニアの自力で考える力がつかないのではないか？
- 自力で叩き台まで作って PR などにして相談する、という時も必要だと思う、その際も 100 % 作りきる前に相談するのが良い
- また効率的なレビューをした結果、時間が空くはずなのでその分を自学に充てるのもあり
触発された記事とか
Pull Request レビューの限界｜qsona｜note
むしろ、根底に関わるような重要な設計相談はそれ以前に会話なりモブプログラミングなりですべき
コードレビューで指摘するたびにいちいちイライラされるプログラマーには致命的なバグでもない限り何も言わないのが正解だと思いますか？ - Quora
動いているなら何も言わないのが正解のひとつと思います。 また、かわりに自分が直してあげたり、ペアプログラミングした方がいいでしょう。
