こんにちは。普段フロントエンドで開発を行っている二年目のSです。
リレーブログ企画第三週は✨技術者のルーティン紹介✨ということで、今回はPull Request（以降PR）のレビューについて、自分なりの方法をご紹介できればなと思います。
また、PRレビューの速度について、Googleのドキュメントを見つけたので、そちらもご紹介します。
前提として
私のチームはフロントエンドが6人いて、PRをオープンすると、その中からランダムに必ず二人がレビュアーとして割り当てられる仕組みになっています。
レビュアー2人がapproveしない限りマージできません。日によりますが、1日3つ以上はレビュアーに割り当てられている感覚です。
レビューはすぐ見るべき？
Googleが公開しているオープンソースのドキュメントに、PRレビューのベストプラクティスをまとめたものがあります。
どれも参考になる内容ですが、Speed of Code Reviews（コードレビューの速度）には、レビューはできるだけ早く対応すべきで、遅くとも一営業日以内にはレスポンスを返そうという内容が書かれています。レビューが遅れるとチーム全体の開発速度が落ちてしまうため、そこは避けたほうがよいというのが大きな主張のようです。
ただ、それだけではなくて、Speed vs. Interruption（速度 vs 中断）やFast Responses（素早いレスポンス）という見出しで、例外についても触れられています。
ざっくり言うと、コーディングに集中しているときに無理やり手を止めてまでレビューする必要はないということです。自分の作業を中断するコストのほうが、相手を少し待たせるコストより高くついてしまうためです。代わりに、タスク完了後・昼食後・会議後などの区切りで対応することが書かれています。
そして、ここでいう早さは、レビューを完遂する早さではなくレスポンスの早さを指しているとのことです。すぐに全部を見られなくても、「ここまでは見ました」、「今は少し立て込んでいるので時間をいただきます」といった一言を返すだけでも、依頼した側のストレスはぐっと下がるそうです。
私はちょうどレビューをどのタイミングで見るべきか悩んでいたので、この部分を読んでとても腑に落ちました。
私はどうしているか
わたしは基本、以下をレビュータイムとしています。
- 出社してすぐ
- 昼休み明けてすぐ
- 夕方（15時～16時くらい）
ただ、完全に固定というわけではなくて、一息ついたら依頼が来てないか確認という感じです。 まず一度開いて、PRの概要とファイル変更数を見ます。それでサクッと済みそうなら、その場で見てレビューします。逆に、重そうな内容なら次のレビュータイムに回しています。
正直これが正しいとは思っていません。一番良いのは即レビューだと思います。
とはいえ、現実的には全員がいつでも即レビューできるわけではありません。だからこそ、個人の工夫だけに頼るのではなく、チームとしての取り決めもあったほうがよいのかなと思っています。
今回Googleのドキュメントを読んで思ったのは、チームの中でPRに対するレスポンスの期限を決めておくことが大事なのではないかということです。例えば、一営業日以内には必ずレスポンスを返すといった感じです。ここでいうレスポンスは、前述のとおりレビューの完遂とは限らず、「ここまでは見ておきました」といった一言も含めてのものです。
あわせて、PRの概要に「どこを確認してほしいのか」を的確にまとめることも大切です。レビューする側の負荷を下げる気遣いも大事だと思います。
最終的には、チーム全体で「ここだけは守る」という最低ラインを決めたうえで、その範囲の中で自分が一番無理なくレビューできる形を見つけていくのがいいのかなと思いました。みなさんもぜひ、自分に最適なレビューの方法を探してみてください。
おわりに
KENTEMでは、様々な拠点でエンジニアを大募集しています！ 建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。 recruit.kentem.jp career.kentem.jp
