コードレビューが上手い人は何を読んでいるのか

この記事は約 5 分で読めます。

レビューの質は「引き出しの数」で決まる

コードレビューで「LGTM」としか書けない人と、設計の意図を汲み取って代替案を提示できる人。この差はどこから来るのでしょうか。

経験年数だけでは説明がつきません。10 年選手でも表面的な指摘しかできない人がいる一方で、3 年目でも本質的な改善提案ができる人がいます。観察してみると、後者には共通点があります。特定のジャンルの本を繰り返し読んでいるのです。

レビュー力を支える 3 つの読書領域

1. リファクタリングの語彙

レビューで最も役立つのは、リファクタリングパターンの知識です。「この部分、Extract Method で分割すると読みやすくなりますね」「ここは Replace Conditional with Polymorphism のパターンが使えそうです」。パターンの名前を知っていると、改善提案が具体的になります。

名前を知らなくても同じ指摘はできますが、「この if 文が長いので何とかしてください」と「Strategy パターンで条件分岐を解消できます」では、レビューを受ける側の学びが違います。パターン名は共通言語として機能し、チーム全体の設計力を引き上げます。

2. 設計原則の判断基準

「この設計は良いのか悪いのか」を判断するには、判断基準が必要です。SOLID 原則、凝集度と結合度、関心の分離。これらの原則を知っていると、コードの良し悪しを感覚ではなく論理で説明できます。

「なんとなく読みにくい」ではなく「単一責任の原則に反しているため、このクラスは 2 つに分割すべきです」と言える。この違いが、レビューの説得力を決定的に変えます。

3. 言語やフレームワークの慣用句

どの言語にも「こう書くのが自然」という慣用的な書き方があります。Python なら内包表記、Ruby ならブロック、Go ならエラーハンドリングのパターン。慣用句を知っていると、「動くけど不自然なコード」を見抜けます。

この知識は公式ドキュメントだけでは身につきません。その言語のベストプラクティスを体系的にまとめた本を 1 冊読むことで、慣用句の引き出しが一気に増えます。

レビュー力を高める読書の順序

まだリファクタリングの本を読んでいないなら、そこから始めてください。リファクタリングの語彙は、レビューで最も即効性があります。コードの問題点を具体的なパターン名で指摘できるようになるだけで、レビューの質が劇的に変わります。

次に設計原則の本を読みます。リファクタリングが「How (どう直すか)」なら、設計原則は「Why (なぜ直すべきか)」です。この 2 つが揃うと、レビューコメントに「こう直すべきです。なぜなら〜」という構造が生まれます。

最後に、チームで使っている言語やフレームワークの慣用句を学ぶ本を読みます。リファクタリングの本から始めて、設計原則、言語固有のベストプラクティスへと進むのが最短ルートです。

レビューしながら読書テーマを見つける

読書がレビュー力を高めるのと同時に、レビューが読書テーマを教えてくれます。

レビュー中に「この設計が良いのか悪いのか判断できない」と感じた箇所があれば、それが次に読むべき本のテーマです。並行処理のコードが判断できないなら並行処理の本を、データベース設計が判断できないならデータモデリングの本を読む。実務の課題から逆算して読む本を選ぶと、読書の動機が強くなり、学んだ内容がすぐに活きます。

関連記事

• Pull Request が通らない人に足りないのは、たいてい語彙力
• 設計・アーキテクチャ本ガイド - 設計力を上げる技術書の選び方

まとめ

コードレビューが上手い人は、リファクタリングの語彙、設計原則の判断基準、言語の慣用句という 3 つの引き出しを持っています。これらは経験だけでは効率よく身につきません。体系的にまとめられた本を読むことで、引き出しの数を短期間で増やせます。次のレビューで「具体的な改善提案ができなかった」と感じたら、それが本を開くタイミングです。