💭

レビュアーにやさしいPull Requestとはなにか

2021/09/06に公開

チーム開発をしていると毎日のようにPR(Pull Request)をレビューしたりレビューしてもらったりする。
そのなかで目的や解決したいこと、その経緯がわからないものをたまに見かける。
レビューに時間がかかると後続のタスクに進めなかったり、積もり積もってリリースまでのリードタイムが長くなったりする。

これを改善するにはどうしたらいいのか。

答えはPRの質にあると感じるので筆者が日頃から気を付けていることをまとめる。

PRのタイトルは短く簡潔に書く
- たとえば「Userの名前を更新できるようにした」
- パッとどんなことをしているPRなのかを伝えられるようにする
PRのタイトルにないことは含めない
- 「Userの名前を更新できるようにした」のPRで「Userの取得にtypoがあったので修正」はしない
- ↑のような修正は別PRにする
PRのdescriptionに詳しい経緯を書く
- たとえば「苗字変更に対応するために名前を更新できるようにした」
- バグ修正などは再現方法や修正前後の動作確認などがあるとよい
1PRで10コミットまで
- 大量のコミットがあったらレビューする気が失せちゃう
- 紆余曲折がんばった跡はgit rebaseなどで消しておく
- レビューする人の拘束時間が長くなる
コミットメッセージにはWhyを書く
- たとえば「Userに関するファイルをまとめるためにディレクトリ追加」
- 「fix」とか「レビュー対応」は内容と経緯がわからない
依存している順にコミットを積む
- 新設メソッドを叩くコード追加コミット -> メソッド追加コミットだと順番がおかしい
- git rebaseでまとめたり順番を整えたりする
ぱっと見わからない工夫などをコメントする
- 質問コメントに答える時間を省く
- 経緯がわかればコードが読みやすい
指摘コメントに感謝の言葉と修正コミットのリンクを貼る
- まずは感謝
- 指定コメントに対する修正がパッと見れる

最後に筆者が教訓にしている記事を貼っておく。

いかがだろうか。

無意識にやっていて列挙できなかったものがあるかもしれないが、上記をようなことに気をつけてPRをつくるとレビュアーにやさしいPRをつくることができる。人間は忘れる生き物なので、あとから見てもわかりやすいものを心がけていきたい。

Discussion