「レビュアーに優しいプルリクエスト」について考えたい

私たちのチームでも、「レビュアーに優しいプルリクエスト」の作成を目指しています。しかし、現状ではプルリクエストの変更行数が多く、レビュー環境が整っていないという問題があります。これらの問題を解決するための具体的な対策を知りたいです。

また、以下の記事にあるように、プルリクエストが巨大化すると、フィードバックの遅延、レビュアーの時間拘束、コードの保守性の低下といった弊害が生じることは重々承知しているのですが、

Pull Requestを小さくする戦略
https://agilejourney.uzabase.com/entry/2023/07/31/103000

これらの弊害を防ぐために、プルリクエストをどのように分割し、どのタイミングでレビュー依頼をすべきか、また、品質と保守性を向上させるためにはどのようなテストの書き方をすべきかについてもアドバイスをいただきたいです。

「レビュアーに優しいプルリクエスト」について、皆さんからの具体的なアドバイスや実践的な方法を教えていただけますでしょうか。
(編集済み)
1年前
view数 322
  • 1
  • 1
  • 1

回答を投稿して企業にアピールしましょう!

Q&Aで投稿された回答は、
企業側に表示されるプロフィールにも投稿履歴として表示されます。

Offersにログイン・新規登録して、気になるテーマやトピックを話してみよう!

\回答があります!/

  • KAWASHIMA Yoshiyuki

    エンジニア

    1年前

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

    またどんなに少ない変更量であっても、複数の変更理由が一つのプルリクエストに混ざっている場合、認知負荷は高いと判断して分割するべきだと考えています。
    view数 24
    • 和田健太郎

      エンジニア

      1年前

      プルリクの巨大化による弊害はおっしゃるとおりなので、上手く解決したいところですね。
      背景などは組織やプロダクトに寄っても変わるので、あくまで個人の体験として回答いたします。

      ■プルリクは小さくする(ために設計からレビューする)
      ・「小さくしよう」というスローガンだけで現場が実践できれば世話なく、基本的には理由があるという前提で当たります。
      ・概ねの場合は「どのくらいの粒度で切ればいいかの感覚がない」「小さくするやり方がわからない」なので、その部分をレビューしながらすり合わせします
      ・この場合「設計」として指しているのは「変更関連箇所の明文化」と「ソースコードの変更該当箇所の指定」です。Classの該当箇所や、初心者の場合はこの辺に書いてほしい、という行数まで指定することもあります。
      ・上記を指定することで、「ここの変更を加えたら一旦レビューを貰いに来てくれ」という指示にすることができるので、割と気に行っています。
      ・こちらがどのくらいの粒度で出してほしいかの肌感を、いきなり開発者とドンピシャ揃えるのは無理なので、やはりコミュニケーションとって徐々に阿吽の呼吸に持ってくほかないですね。

      お目汚し程度になれば幸いです。
      view数 63
      • Takuo Doi

        エンジニア

        1年前

        状況による部分が非常に大きいので、期待されている形の回答ではないかもしれませんが。

        まず、なぜ「レビュアーに優しいプルリクエスト」にしたいのかから考えてみてはいかがでしょうか?
        恐らくですが、レビューがボトルネックになって生産性が落ちていると感じているからかとは思います。
        ですが、その時間は、品質と保守性を向上させるためには必要な時間なのかもしれません。

        おしゃられるように、プルリクエストのサイズの問題かもしれませんが、それは、ユーザスーリーや、タスクの大きさの問題かもしれません。もしくは、これまでの技術的負債の影響かもしれません。そもそもレビューの必要性を疑ってみてもいいかもしれません。ペアプロやモブプロが解決策になるかもしれません。

        品質の高いコードを生産性高く開発したいというのは、誰もが求めるものです。
        では、品質の高いコードって何ですか?生産性が高いって何を意味していますか?
        きっと、プロジェクト、チームごとに求めるものも違ってきます。

        あなたが、スクラムチームのメンバーだと想像して書きますが、仮にここで素晴しい回答に見えるものが得られたとしても、それはチームが目指すものなのでしょうか?銀の弾丸はありません。ぜひ、あなたの思いをチームに伝えて、チームが目指すべき場所に向かって改善を繰り返していかれることを期待します。
        view数 43