システム開発や改修を行う際は、コードレビューを行うという現場がほとんどでしょう。ただ、コードレビューを効果的に行えているかと言われると、個人的な感触だとあまりそういう現場は多くないような感じがして、コードレビューに関する課題は何かしらある気はします。私も仕事でレビューすることがあるのですが、バグであったりイケてないところを見過ごしたりしてしまって、やはりきっちりチェックするのは中々難しいなと思ってます。
では、そもそもコードレビューって、どんなことチェックするのかって話ですが、基本的な内容としては以下の記事にある通り、機能面・コードの書き方・パフォーマンス辺りになってくるかなとは思います。
上記の記事にあるような内容を、漏れなく人目でチェックするというのは、やはり厳しい時もあるでしょう。個人的には、以下の記事のような「雰囲気よさそう」みたいな感覚が近いです。自分がレビューしても後々バグが出たこともあったし、逆に他の人にレビューしてもらってもバグになったこともあるし、やはり完璧にレビューをするというのは現実的ではないなとは感じています。
なので、レビューの位置付けについて下記の記事にある通り「クリティカルな問題について「レビュー = 最後の砦」といった状況は可能な限り避けるべき」というのは基本的に同意です。もちろんコードをチェックすることは大事ですが、「信用を評価」や「危険な兆候」といった人間的な面も大事かなとは思います。
以下の記事に書いてある「コードレビューは同期のための手段のひとつでもある」という考え方もありだと思います。コードだけを渡されてそれをチェックするよりも、プルリクエストに修正の背景や考え方などが整理されてた方が、それを読むことで認識齟齬は少なくできるでしょう。
レビューを位置付けが不明確なまま行うよりは、チームマネジメントの観点からコミュニケーションを取る位置付けとすると、やり方とかも変わってくるかもしれませんね。
