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

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

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

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

経験年数だけでは説明がつきません。10 年選手でも表面的な指摘しかできない人がいる一方で、3 年目でも本質的な改善提案ができる人がいます。差が出るのは、感じたことを言葉にする段階です。「ここは直したほうがよい」と思っても、その違和感を名前のついた概念に結びつけられなければ、コメントは「読みにくい」で止まります。逆に、手法名や設計原則という既製の言葉を持っていれば、違和感をそのまま相手に渡せます。この既製の言葉は実務で自然に湧いてくるものではなく、体系的にまとめられた本から借りてくるものです。

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

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

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

なお、名前は版で変わります。関数の抽出は Extract Method という名前で広まりましたが、公式のリファクタリングカタログでは現在 Extract Function が正式名で、Extract Method は旧称として併記されています (2026 年 8 月時点)。チーム内で旧称が定着しているなら言い換える必要はありませんが、書籍や記事を横断して調べるときは両方の名前で当たると取りこぼしが減ります。

名前を知らなくても同じ指摘はできますが、「この if 文が長いので何とかしてください」と「Strategy パターンで条件分岐を解消できます」では、レビューを受ける側の学びが違います。手法名は共通言語として機能し、あとで調べ直すときの検索語にもなります。

ただし、名前だけを投げるのは逆効果です。相手がその名前を知らなければ、コメントは指示ではなく宿題になります。名前を出すときは「Strategy パターン (条件ごとの処理を別のクラスに分け、差し替えられるようにする形) が使えそうです」のように、一行で中身を添えるか、参照先を示してください。

2. 設計原則の判断基準

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

「なんとなく読みにくい」ではなく「このクラスは変更の理由が 2 つあるので、単一責任の原則に照らすと分割の候補です」と言えます。原則を根拠にできると、指摘は好みの押しつけではなく議論の土台になります。

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

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

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

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

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

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

最後に、チームで使っている言語やフレームワークの慣用句を学ぶ本を読みます。リファクタリング、設計原則、言語固有のベストプラクティスの順に進めると、前に読んだ内容が次の判断の土台になります。逆順だと、慣用句を覚えても「なぜその書き方が自然なのか」を説明できません。

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

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

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

関連記事

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

まとめ

具体的な改善提案ができるコメントは、リファクタリングの手法名、設計原則、言語の慣用句のどれかを裏づけにしています。この 3 つは実務で偶然出会うのを待つより、体系的にまとめられた本でまとめて借りてくるほうが早く揃います。次のレビューで「具体的な改善提案ができなかった」と感じたら、それが本を開くタイミングです。