この記事は リンクバルアドベントカレンダー2023 の10日目の記事です。
昨日は @dkdidudtn さんの記事です！
はじめに
コードレビューで、依頼されたレビューが溜まりがちだったりレビューする時間が取れないというあなたに、解決策になるかもしれないコツを3つ紹介します。
もったいぶらずにまず結論を書きます。
-
レビュー依頼されたらすぐに目を通す
- これがかなり重要だと私は捉えています
- レビューのハードルを上げない
- わからないことは依頼者にすぐ聞く
なぜレビューが溜まるのか
溜まる理由、それはあなたが溜めているからです（進次郎構文）。
これはあながち間違いではなくて、真面目に書くと、コツの3つとは逆の考え・行動をしていることが理由です。
もちろん理由のすべてではないですが、これらがそれなりの割合を占めている気がします。
- レビュー依頼されたらすぐに目を通す
→ すぐ見ないからどんどんレビューが溜まっていく - レビューのハードルを上げない
→ （勝手に）ハードルを上げて、見ていない or 確認中のレビューが溜まっていく - わからないことは依頼者にすぐ聞く
→ 自分で調べて時間を使ったり、あとで調べようとしてレビューが溜まっていく
最後の1つは悪いとは思いませんが、それでレビューが遅れたり時間を使いすぎるなら悪だと思います。
以降でそれぞれのコツについて詳細を書きます。
少し話がそれますが、レビューが溜まる原因には大きなプルリクエスト/マージリクエストというのがあります。
とはいえいろいろな事情で大きくなってしまうこともあるでしょうし、これはレビュー依頼者（やチーム）が原因なので、その問題と切り分けて読んでもらえると助かります！
1. レビュー依頼されたらすぐに目を通す
「目を通す」は、レビューを終わらせることではありません。
まずはサッと見て、全体像を把握することです。
メリットがいくつかあります。
抽象度高めのわからないことを早期に把握できる
5分でも真面目に見れば、レビュー対象の抽象度が高めのわからない部分が把握できます。
抽象度が高めということが大事で、そこを把握しないと具体的なコードがいいかどうかは判断できません。
例えば以下のような部分
- issueとの関係性
- この解決策でいいのかどうか
- ディレクトリやクラスなどの大枠の構成
抽象度が高めの疑問点が湧いたら、レビュー依頼者に確認しましょう。
そこを解決できたら、具体的な部分のレビューが捗ります。
というかそこを解決せずに具体的な部分を見ても、無駄に終わる可能性すらあります。
依頼者向け：抽象度が高いことは早めに合意を得ておく
規模や工数などにもよりますが、私は抽象度が高いことは、レビュー依頼者が早めに関係者と合意を得ることがいいと思います。
例えば、issueを解決するために複数の選択肢がある中からライブラリを1つ導入するとします。
であれば、そのライブラリに決めることをまず合意を得ておけば、その後の作業が無駄にならないので。
もし具体的に実装進めて「やっぱこのライブラリは無理」となったら、他のライブラリを検討すればいいだけなので。
もちろん、具体的に実装進めるパートが1,2時間で試せるなら、試しちゃったほうがスムーズかもしれませんけどね。
あと、レビュー対象に抽象度が異なるものが存在すると、レビュワーが先に具体的な部分に目がいってしまうことは発生してしまいます。
特に、経験が浅いとそうなりやすい気がします。
そうならないためにも、レビュー対象の粒度の幅を狭くする、みたいな。
レビュー依頼者に「放置されていない」という安心感を与える
レビューのコメントなりを一つはしている前提ですが、そうすれば依頼側は、「まだ見てもらえていないのかな」という不安を抱かずに済みます。
レビューのコメントなにも出ていないなら、とりあえず「X日までには見ます」くらいコメントしておけば安心でしょう。
「見てもらえているかわからない」「いつ見てもらえるか/終わるかがわからない」といった状況は、依頼者にストレスを結構与えてしまうので。
レビューにかかる工数をざっと把握できる
「抽象度高めの〜」と通ずる部分で、サッと目を通しておけば、レビューにどれくらい時間がかかりそうか把握できます。
把握できれば、「今レビューを終わらせる」「次の会議が終わったら集中して見よう」といった選択ができます。
2. レビューのハードルを上げない
「issueの目的や仕様を把握し、すべてのコードをすみずみまで確認しないといけない」みたいなことを思っていると、しんどいです。
しんどくて、レビューが進みません。
その心構えはマイナス影響が出ないなら構いませんが、それでレビューが遅くなるならやめたほうがいいと思います！
次のような心構えでいることを私はおすすめします。
- 一度に全部見なくてもいい
- 指摘が間違っていてもよい（場合による）
- 理解が間違っていてもよい（場合による）
- わからないことは積極的に聞こう
そもそも、「すみずみまで確認しないといけない」というようなレビューの要件(？)を決めるのは、依頼者やその上司だと思います。
そうでない人が勝手にハードル上げてレビューが遅くなったりレビューに時間を使いすぎることは、誰も望んでいないはずです。
その他参考記事
次の記事は目を通すだけでなく終わらすところまでかもしれませんが、「レビュー依頼が来たら即座にレビュー」の項目があります。
好評だったそうです！
他にもすごい参考になる内容なので、ぜひご一読いただくことをおすすめします！
3.わからないことは依頼者にすぐ聞く
レビューしていると、わからないことがたくさん出てきます。
- このプルリクエストで解決したいことは？
- なぜこの選択で解決するの？
- なぜこのクラス構造なの？
- なぜこのライブラリなの？
- なぜこのコードを消しているの？
- どれくらい細かく確認する必要があるの？
これらの疑問をレビュワーが一つ一つ自分で調べて解決するのは構いません。
が、前にも書きましたが、それでレビューが遅れたり時間を使いすぎるのは避けたほうがよいでしょう。
一番把握しているのはレビュー依頼者なので、であれば調べてすぐ解決できない疑問は本人に質問しましょう。
レビュー依頼者向け：出そうな疑問を先に潰しておく
そのまんまです。
以下の記事が全体的にとても参考になり、特に「どの程度コードを確認してもらいたいかをしっかりアピールする」がわかりやすいです。
この記事を読んでから、私もdescriptionnに優先度やレビュー度合いを書くようになりました。
依頼者向け：わからない理由とそれを潰す努力をする
わからない理由は、レビュワー（スキルや知識）とレビュー対象物の2つにあります。
これは私の個人的な考えですが、依頼している以上はレビュワーがわかるようにすべきで、であればdescriptionなりコメントなり口頭での説明なりをしたほうがよいでしょう。
レビュワーがスムーズにレビューできる努力を依頼者はすると、結果的に早くレビューしてもらえるでしょうし、レビュワーの時間も減りますし、レビューでのやり取りも減ります。
おわりに
仕事術的な意味でのコツでした。
「仕事術的」と書いているとおり、ここまでの話はコードレビューに限らず、どの仕事にも適用可能です。
例えば、営業資料をレビューするとか、新しい企画をレビューするとかです。
レビュワー側のコツとして書きましたが、レビュー依頼者はレビュワーがコツを実践しやすいよう行動すれば、溜められずにスムーズにレビューしてもらいやすくなるでしょう！
・・・とまここまで偉そうにいろいろ書いてきましたが、私もできていないときはあるので、努力します。
チームの仕組みとしてこれらができるようにしたいですね！