＼回答があります！／

• 

  KAWASHIMA Yoshiyuki

  エンジニア

  1年前
  レビュワーの認知負荷を軽くするのが優しさだと考えています。
  認知負荷を軽くするには、コード変更量よりも、コードの変更理由が一つであることが望ましいと思っています。
  既存の設計上の課題のため、変更理由が一つであってもたくさんの差分が発生するケースはあり得ますが、それは1つのプルリクエストである方が認知負荷は軽いと判断しています。
  
  またどんなに少ない変更量であっても、複数の変更理由が一つのプルリクエストに混ざっている場合、認知負荷は高いと判断して分割するべきだと考えています。
  view数 24

• 

  和田健太郎

  エンジニア

  1年前
  プルリクの巨大化による弊害はおっしゃるとおりなので、上手く解決したいところですね。
  背景などは組織やプロダクトに寄っても変わるので、あくまで個人の体験として回答いたします。
  
  ■プルリクは小さくする（ために設計からレビューする）
  ・「小さくしよう」というスローガンだけで現場が実践できれば世話なく、基本的には理由があるという前提で当たります。
  ・概ねの場合は「どのくらいの粒度で切ればいいかの感覚がない」「小さくするやり方がわからない」なので、その部分をレビューしながらすり合わせします
  ・この場合「設計」として指しているのは「変更関連箇所の明文化」と「ソースコードの変更該当箇所の指定」です。Classの該当箇所や、初心者の場合はこの辺に書いてほしい、という行数まで指定することもあります。
  ・上記を指定することで、「ここの変更を加えたら一旦レビューを貰いに来てくれ」という指示にすることができるので、割と気に行っています。
  ・こちらがどのくらいの粒度で出してほしいかの肌感を、いきなり開発者とドンピシャ揃えるのは無理なので、やはりコミュニケーションとって徐々に阿吽の呼吸に持ってくほかないですね。
  
  お目汚し程度になれば幸いです。
  view数 63

• 

  Takuo Doi

  エンジニア

  1年前
  状況による部分が非常に大きいので、期待されている形の回答ではないかもしれませんが。
  
  まず、なぜ「レビュアーに優しいプルリクエスト」にしたいのかから考えてみてはいかがでしょうか？
  恐らくですが、レビューがボトルネックになって生産性が落ちていると感じているからかとは思います。
  ですが、その時間は、品質と保守性を向上させるためには必要な時間なのかもしれません。
  
  おしゃられるように、プルリクエストのサイズの問題かもしれませんが、それは、ユーザスーリーや、タスクの大きさの問題かもしれません。もしくは、これまでの技術的負債の影響かもしれません。そもそもレビューの必要性を疑ってみてもいいかもしれません。ペアプロやモブプロが解決策になるかもしれません。
  
  品質の高いコードを生産性高く開発したいというのは、誰もが求めるものです。
  では、品質の高いコードって何ですか？生産性が高いって何を意味していますか？
  きっと、プロジェクト、チームごとに求めるものも違ってきます。
  
  あなたが、スクラムチームのメンバーだと想像して書きますが、仮にここで素晴しい回答に見えるものが得られたとしても、それはチームが目指すものなのでしょうか？銀の弾丸はありません。ぜひ、あなたの思いをチームに伝えて、チームが目指すべき場所に向かって改善を繰り返していかれることを期待します。
  view数 43