コードレビューの意義
忘れそうなので下書き
僕の中での、「コードレビューを行うことの意義」は、ざっくりと
- 1 ロジックやデータ構造が明らかに間違っているコードが、メインラインに取り込まれることを防ぐため。 (最後のチェックポイント)
- 2 改善の余地があるコードをレビューでフィードバックすることで、レビュイーの勉強を促すため。 (レビュイーの学習)
- 3 レビュワーが、他の人のコードを意識して読むことによって、レビュワー自身の勉強になるため。 (レビュワーの学習)
があると思っている。
1 は、「diffと周辺のコードだけ」を見ることで明らかに間違っているコードを見つけることであって、全体的な動作や他システムとの結合部分を確認・担保するのまでは、レビュワーにさせるのは負担が大きすぎるため、それはレビュイーの責任だと思っている。
それよりも大きなコードの追加・修正があるなら、レビュイーは相談したりdesign docを書いたりして、コードを書く前に「今から実装しようとしているモノの方向性は正しいのか？」を確かめたほうが良いと思う。
また、コードをすべて書き終わってからコードレビュー依頼を投げるのではなく、実装途中や中身がTODOコメントの状態でレビューを投げて議論を行い、早いうちにすり合わせたほうが、後から大きくやり直すことは少なくなると思う。
2 は、(僕自身がそうだったからなのだけど、)慣れていない言語・フレームワークだと、自分ひとりで勉強するのは限界があるので、慣れているメンバーからレビューしてもらうことで、レビュイーのスキルアップが早く大きく見込めると思う。
より実践的な言語・フレームワークの書き方を教えてもらえたりすれば、そのPRで修正するのもできるし、何らかの理由で見送る場合だとしても、次からはより良いコードが書けるようになる。
3 は、(これも僕自身がそうだったからなのだけど、)他の人が書いたコードを読むと、「そういう書き方があったのか」とか「前に他の書き方をしちゃったけど、レビューしたこのコードの方が見通しがいいな」みたいな発見があるので、これもコードレビューの意義としてあるのではないかと思う。
じゃあ、上に書いた 1 2 3 のような効果を得られる、効果的なレビュワーはどうするのが良いか？というのは、
- 担当範囲が近い人 (1の効果)
- 自分よりシニアだと思う人 (1, 2の効果)
- 自分と同じくらいか自分よりジュニアだと思う人 (3の効果)
にお願いするのが良いのかなと思う。
3人にお願いしないといけないわけではなく、↑の条件を満たせるなら2人でも良いだろうと思う。
