hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

レビュワーランダムアサインの使いづらさ

以前は手作りのおみくじを使ったり、GitHubのCode review assignmentを使ったりで、レビュワーをランダムアサインする暮らしを続けているけど、いまいち使いづらい点がある。

  • 知ってるところで呼ばれるならいいけど、いきなり全然知らないところを読むことになると腰が重い
  • Pull Requestが何個かセットで完成するようなシリーズ物の場合に一部だけ見ても理解できない
  • レビューにかかる手間を考えると、実装の大きさは最小になっていることが求められるので、追加でリファクタリングとか、品質アップとか、ついでにここも直したよ、とか、根本対応、みたいなことをやりづらい
    • 特に、このことを最近思うようになってきた


これがコードレビューじゃなくて設計レビューなら、毎日別の人に話しかけるということはしなくて、手伝ってくれる余裕のある人を探して相談に行くし、そういう余裕のある人が居ないなら、設計レビューできる人がいないなら、今この開発はできませんね、となる。
レビューコストも誰かの時間を取っているわけなので、思考停止して、おみくじすれば時間や人は出てくるじゃん、じゃなくて、これからこういう、大きめのものを作るのでレビュー手伝ってもらえませんか、みたいな話をして、先に協力をお願いして、おけるとよいのだろう。
その上で、たしかにリファクタリングしたほうがいいのでレビューがんばります、みたいに合意できればお願いできそうだし、場合によっては、今この規模のものをレビューする余裕はないので、今回は実装しない、という流れもありえると思う。


先月も似たようなことを考えていた。ここでいう1と2の間で、1.5の立場で、たびたび見ているけどよさそう、という粒度の様子見具合になってほしい場合がある。
blog.sushi.money


おみくじじゃなくて、ここのコンポーネントはこの人が作ったよ、おすすめ、という推薦にしたがってレビューをお願いしていくほうが、やりたいことには近いかもしれない。
これだと、全然知らない部分のリファクタリングをいきなり見せられることはないし、シリーズになってるなら、だいたい同じようなメンバーが推薦されてきそう。

f:id:hitode909:20211217070738p:plain
レビュワーの推薦機能
Pull Request レビューをリクエストする - GitHub Docs