プルリクエストで心掛けること
最近、社内のチームでプルリクエストの運用を開始しました。
以前から個人的には数回行っていましたが、いまいちうまく機能しなかったので、チーム内でプルリクで心掛けることを改めて話し合いました。
プルリクエストのタイミング
- WIP RP(Work In Progress Pull Request)の方式を採用する
- コードを書き始めた段階からプルリクを発行し、設計の序盤からレビューしてもらえる体制をとる
- とても小さな変更で、設計者に不安がない場合はプルリクは不要とする
→これはプルリクの乱立により、より重要なプルリクを見落とさないため
当初はWIP PRを知らなかったため、設計完了してからプルリクを登録しており、レビュワーも割り込み作業という感覚が強かったです。そのため、「プルリクエストをリリース間近に出しても見れないよね」という切り口から話題に上がりました。
WIP PRを行うことで、レビュワーの負担も少なくなります。また、序盤で指摘されれば、手戻りも少なくて済みます。
プルリクエスト登録時のコメント
- レビューしてほしいポイントを記載する
- 完了希望日を明記する
- 仕様に関する情報などを記載する（Redmineのチケット情報など）
レビュイーがレビュワーに必要な情報を記載することにしています。プルリクが登録されたけど、変更点多すぎてどこを見たらいいかわからい、いつまでに見たらいいの、などの意見がありました。
特に重視したいのはレビューしてほしいポイントを伝えることです。レビュワーも効率よくレビューすることができ、内容によっては「そこよりもこっちのほうが問題だよね！？」みたいな温度差も分かりやすくなるのでいいのでは、とも思ってます。
コードレビューする文化があまり育っていない環境なので、これを機に気軽にレビューできるようになればいいな！
