コードレビューは、ケアレスミスによるバグの防止や実装方法の統一性の維持など、うまく運用できれば高い効果が得られます。
とは言っても、きちんとレビューしようとすると時間がかかるので、レビューを依頼されても忙しいとつい優先度を下げてしまいがちです。
しかし、コードレビューは後回しにすべきではありません。むしろ、自身のタスクよりも優先して取り組むべきです。
※レビューの手法や形式については、ここでは問いません
人というのは忘れる生き物です。
実装して何日も経ってから「ここ、こうした方がいいと思うんだけど」などと言われても、「あれ…どうしてこうしたんだっけ？まあ、言われた方法の方が良さそうだから直しとこう」となってしまいます。
一方、実装直後に指摘してもらえると、「こう思って書いたけど、確かにこっちの方が良さそうだ。こういうやり方があったのか」のように、実装時に気付かなかった部分や足りなかった部分が明確に認識できるため、本人の成長、そしてチームの成長につながります。
それに、実装したときのことをはっきり覚えている内に指摘してもらえると、「こういう可能性があるから、あえてこう書いてるんです」のように、指摘に対する反論もしやすいです。
結果として、指摘通りに修正したけどテストでバグが発生したから結局元に戻す、のような二度手間の防止になります。
また、レビュー依頼から期間が空いてしまった場合、レビュー依頼者が既に次のタスクに専念してしまっている可能性があります。
そのタイミングでレビューされてもし何か指摘事項があったら、今のタスクを中断した上で、前のタスクに頭を切り替えなければいけません。
さらに、指摘されたのと同じ間違いを次のタスクでも犯していた場合、そちらも修正することになるため、早く指摘してくれれば一カ所で済んだ修正が二カ所になってしまいます。
レビューとはそういうもの、と思っている方は、本当にそれが正しい状態なのか、改善する余地は無いのか、今一度考え直してみた方がいいと思います。
レビュー担当者にとっては何の問題も無いかもしれませんが、チーム全体で見ると大幅な効率低下になっています。
このように、コードレビューというのはある程度の即時性をもって実施しないとせっかくの効果が半減してしまいます。
開発フローにレビューを組み込んでるけどイマイチ効果が無い場合、もしかしたら実装からレビューまでの間隔を縮めるだけで効果が出るようになるかもしれません。