📅

プルリクのレビューは即返す

2023/12/10に公開

はじめに

CARTA HOLDINGS アドベントカレンダーの12/10の記事です。

ここ最近、レビュー依頼は来たら即返すことを意識してる。
自分がコードを書いている最中でも、レビュー依頼が来たら手を止めて即返す。
流石にMTG中は返さないけど、終わって一息ついたら返す。

なんで意識することになったか

社内読書会でエクストリームプログラミングを読んだ。
その時に、ソフトウェア開発の無駄の話になった。

ソフトウェア開発におけるムダ
長すぎるフィードバックプロセス
https://www.ryuzee.com/contents/blog/5738

レビュー待ちの時間がムダと感じるのはどこでも共通なんだなって思った。

また、エクストリームプログラミングには制約理論の話が書いてあった。

洗濯機に45分、乾燥機に90分、衣類をたたむのに15分かかるとする。
このシステムのボトルネックは乾燥だ。洗濯機が2台あっても、洗濯がすべて完了した衣類が増えるわけではない。洗濯だけが終わった衣類は一時的に増えるかもしれないが、濡れたままの衣類が至るところに山積みになり、その対応をしなければいけなくなる。その結果、洗濯がすべて完了した衣類の数は少なくなってしまうだろう。より多くの洗濯をすべて完了捺せたければ、乾燥をどうにかする以外に選択肢はない。
エクストリームプログラミング P.81-82

レビューが乾燥機の位置になってしまうと、それだけで、開発のスループットが落ちてしまう。
が、レビューは乾燥機と違って、本人次第で時間を短縮することもできる。

レビューは依頼がきて、止まっている間は虚無の時間なので、即返ってきたらそれだけ幸せになれるならすぐ返そうぜっていう話。
もちろん丁寧にみた結果時間がかかるのはしかたないとは思うけど。

レビュー待ちの開発者にとって

レビュー依頼者側にとって、レビューが返ってこないことでの不幸ポイントがある。

例えば、レビューの結果次第で実装方針が変わる可能性がある。
早く返ってきてくれるとその分早く修正できるし、その先のタスクへもスムーズへ移行できる。

仮にそのPRに文句がなくてもLGTMが貰えないとリリースができない。
レビュー待ちの状態とレビューの完了であとはリリースするだけの状態とでは気持ちにも大きな差がある。

レビュワー(筆者)にとって

個人的な性格的に、一段落ついたらPR見ると決めたとしても、頭の片隅にレビューを見るというタスクがちらつくのが嫌だった。
だったら、とっととみて、とっとと相手にボールを返すのがwin-winなになる。
後回しにしてもいつか見ないといけないから、今見るてすぐ返す。

そのPRでかくない?

自分の新卒1年目から2年目のとき、弊社の技術力評価会[1]で毎回指摘を受けていた。
当時は、1つのタスクに対して、1つのPRを投げていた。
例えば、ある管理画面を作るときはその管理画面に作成するのに必要なコードすべてを1つのPRにしていた。

これをすると、良くないよねって点がある。

今回の話の流れでいうと、レビュワー的にも、レビューをはやく終わらせるためにはPRの粒度が細かいほうが嬉しい。
レビュワーがいくら早く返そうと意識しても、ファイルチェンジが30とかのPRはそっ閉じしたくなる。後で見ようって気持ちになっちゃう。

PRは1つの目的に対して出してくれるとレビュワーてきにも見やすくて嬉しい。
その点、弊チームはみんな良い感じの粒度でPRを投げてくれるので見やすくて嬉しい。

レビューのしやすさ以外の観点からもPRが良い感じの粒度でくると嬉しい。
その辺の話はnekoyaさんの記事にまとまってる。
https://zenn.dev/nekoya/articles/adc9ec4b08e4f3

あと、レビューが遅くなると、それだけ、PRもでかくなってしまう悪循環があるんじゃないかな〜って思う。
早く返ってこない→1つのPRをデカくする→より早く返ってこない みたいなのありそう。

レビューを即返すために

GitHubのレビューアサインの通知をSlackに流す

GitHubのレビューアサインされたらSlackに通知が来るように設定ができる。
その設定をすれば、すぐきがつける。
自分はその通知が来たら見るようにしてる。

レビュー依頼のPRがでかい場合は小さくしてもらう啓蒙活動をする

前述の通り、でかいPRはそれだけれレビューに時間がかかってしまう。

レビュー依頼者側もレビューが遅い理由は自分にあるかもとおもってみると良いかもしれない。
レビューがし易いようにPRを分割したり、分かりにくくて質問が来るであろうところには先にPR中に補足のコメントを入れたり、背景を理解していたほうがレビューがしやすくなるのでDescriptionになぜやるかの背景を詳しく書いたり。

レビューをすぐ返すぞの気持ちを強く持つ

最後は精神論になるけど、レビューが来たことにすぐ気がつけて、PRが適切な分量であれば、あとは、KIAIで自分がみるだけだと思う。

脚注
  1. 社内の評価制度。https://cartaholdings.co.jp/engineering/tech-assessment/ ↩︎

GitHubで編集を提案

Discussion