コードレビューする時に意識してることをまとめてみた

コードレビューする時にいつも意識してることが頭の中にあるんだけど文章化したことなかったなと思い、いい機会なのでまとめてみました！

実装者に対して、感謝の気持ち・敬意を持ってレビューする

レビューに限った話ではないですね。。
ただやっぱりベースにこの気持ちがあれば、コミュニケーションで問題が起きることはほぼないと思うから大事だよなぁと思ってます。

コードレビューでの指摘はあくまでコードに対することなので人格は関係ないということは分かっていても自分もコードレビューでボコボコに殴られたらやっぱり人格の方も多少傷ついてしまう気がするので、コードを指摘するその先には人がいるということを念頭に敬意を持ってレビューしていきたいですね。

なるべく早くレビューを返す

コードレビューの速さはチーム全体の開発速度の速さに直結すると思っているので、なるべく早くレビューを返すように意識してます。
いつも仕事始めにはまずレビューが必要な PR があるか確認してる。レビューが遅くなりそうなら事前に一声かけるようにしてます。

自分でも動作確認する

当たり前のことかもしれないけど、色々仕事が重なってると確認不足になりがち。
PR の diff 上でのコードの確認より結局動作確認しながらの方が結果的にレビューも早くなって精度も上がると個人的には感じています。

少しでも気になるところがあれば聞く

特にレビュアーより実装者の方が経験があったりスキルが高い場合だと些細だと思うことを聞くのを躊躇ってしまうケースがあると思います（自分はあった）。
気になるところがあるのにそれを聞かなくて Approve するのはレビュアーの役割を放棄してるし実装者に対しても失礼かなと思うようになり、以後気になるところは聞くようになりました。

あと気になって聞いた所は、結果的に改善の余地があったというケースが意外に多かったなと個人的な経験で思います。

何か指摘する場合は自分なりの答え・代案を添える

例えば、「この変数名が抽象的すぎるのでもう少し詳細にしてください」みたいな指摘をもらうと「じゃあどのくらい詳細にどうすればいいんだろう」と自分だったら疑問に思ってしまいます。
なので自分が何かをレビューで指摘する場合は、「自分ならこうするんですがどうでしょう」みたいな自分の案を必ず添えて議論するようにしています。

考える機会を与える方がその人のためになる（特にジュニアの人には）という意見もあるかもしれないですが、
自分が何回もそういうレビューを受けたらちょっと心理的に辛いかなぁと思ってるので、自分はしないようにしてる。

コードでは読み取れない経緯などはコメントに残してもらう

コードで表現されていることについてあえてコメントを必要はないですが、仕様上こういう実装になっているみたいな経緯はコメントに残してもらった方が後々思い返す時に楽だなと思ってます。
自分で実装したのに数ヶ月後には「あれ、なんでこういう実装にしたんだっけ」と忘れてしまう経験が結構あって、割と実装者自身だと気付きにくいポイントだと思うのでレビュアーが意識的に指摘できるといい気がします。

diff 以外の影響範囲も一度考える

PR の diff を見てそこに行単位でコメントをしていくと、どうしても diff 上だけを見てしまう。
実は diff 以外の意図しない箇所まで影響していたり、修正が足りていない所があったりという経験をしたことがあるので、
一度 diff 以外の影響範囲も考えてみるように意識してます。

いいなと思った点も伝える

自分が実装した PR で褒めてもらってすごく嬉しかった経験があるので、自分も意識的に伝えたいなと意識してます。
レビューではどうしても問題点を指摘しようとしてしまうけど、いい点も指摘するとレビューしてもらう側はかなり気持ちが上がる。

終わり

自分の頭の中をドキュメント化して、スッキリしました！
参考になったか分かりませんが、少しでも参考になった所があれば幸いです。