TL;DR

  • 最近、PR(プルリクエスト)をもう少し小さくしたいと考えている
  • 技術単位でPRを分けると、レビュー時に完成形が見えづらいことがある
  • PRを分けることを考えるより、PBIを小さくすることを考えた方が良いかもしれない

はじめに

最近、PR(プルリクエスト)を小さくしたいなと考えています。

今のチームで巨大なPRばかり作られているわけではありません。ただ、レビューする側になった時に「もう少し小さかったら見やすいのにな」と思うことがあります。

というより、むしろ自分が大きいPRを作ってしまうことが多いので、申し訳ないなと思うことがあります。

そんなことを考えていて、少し気になりました。

技術単位でPRを分ける

最初は単純に「機能を複数のPRに分ければいい」と思っていました。

例えば、ある機能を作る時に

  • バックエンドのPR
  • フロントエンドのPR

に分けます。

実際によく見るやり方だと思います。

ただ、自分はこの分割方法のPRを見るのはあまり得意ではありません。

バックエンドだけのPRをレビューしていると、最終的にどんな画面になるのか分からないことがあります。

逆にフロントエンドだけのPRだと、今度はAPIの仕様やデータの流れが見えてきません。

レビュー自体はできます。でも、「この変更によってユーザーが何をできるようになるのか」が見えづらいです。

レビューする側も、頭の中で完成形を補完しながら読む必要がある気がしています。

そう考えると、技術単位でPRを分けることはPRを小さくする方法ではあります。ただ、レビューしやすくする方法とは少し違うのかもしれません。

問題はPRではなくPBIなのかもしれない

このように考えていて思ったのが問題はもっと前から起きていて、それはPBIなのではないでしょうか。

例えば「通知機能を作る」というPBIがあったとします。

これをそのまま実装するとPRは大きくなります。だからPRを分割したくなります。

でも、そもそも

  • 通知一覧を見る
  • 未読状態を表示する
  • 既読にする

のようにPBI自体を分けられるなら、それぞれが1つのPRになります。

PRを分割する必要すらなくなります。

「PRをどう分けるか」を考えていましたが、その前の「PBIをどう分けるか」が重要なんじゃないかと思っています。

おわりに

そもそもPRを小さくする必要があるのかという話もあります。

レビュー時間やレビュー品質との関係もありますし、大きなPRにもメリットはあると思います。

だから「PRは絶対に小さい方が良い」と言いたいわけではありません。

ただ最近、PBIを適切に作ることが良いPRを作ることに繋がるのでは？という発見があったので、まとめてみました。