コードレビューって結局何を見てるんだろう

レビューで何を評価するのか

コードレビューについて考えてみると、純粋に「バグがないか」だけを見てる訳じゃないんだよね。もちろんそれも重要だけど、むしろ「このコードを半年後に別の人が読んでも理解できるか」みたいな視点の方が大切な気がしてる。

最近のプロジェクトで感じるのは、技術的には完璧でも「なぜこんな書き方をしたのか」が伝わらないコードってあるということ。そういう時はコメントを入れてもらったり、別の実装方法を提案したりする。逆に完璧ではなくても「意図が明確で、後から改善しやすい設計になってるな」っていうコードは好印象ですね。

流儀とかスタイルの話

「流儀」って言葉が面白いなって思うのは、チームごと、プロジェクトごとにそれぞれの文化があるってことなんだと思う。ある会社では厳密な型チェックを重視してるかもしれないし、別のチームではテストカバレッジを最優先にしてるかもしれない。

自分は新しいプロジェクトに入る時、コードレビューの指摘内容から「このチームは何を大事にしてるんだろう」って読み取るようにしてます。そっちの方が「なぜそう言われるのか」が腑に落ちやすいんですよ。

難しい部分

ただ、難しいのは「改善の指摘」と「指摘される側のモチベーション」のバランスなんですよね。厳しすぎるレビューって学習にはなるけど、書き手が疲弊することもある。逆に甘すぎると技術負債が溜まっていく。その塩梅ってどうやって作るんだろう？