コードを「書く力」と「読む力」は別物 - 読解力を鍛える技術書の使い方

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

書けるけど読めない問題

自分でコードを書くのは得意なのに、他人のコードを読むのが苦手。オープンソースのコードを追おうとしても、すぐに迷子になる。コードレビューで「何をやっているか」は分かるが「なぜそう書いたか」が読み取れない。

この問題を抱えるエンジニアは多いのに、「コードの読み方」を体系的に学ぶ機会はほとんどありません。プログラミング教育は「書く」ことに偏っていて、「読む」訓練が圧倒的に不足しています。

書く力と読む力が別物である理由

自然言語と同じです。日本語で文章を書ける人が、全員、法律文書や学術論文をスラスラ読めるわけではありません。書く力は自分の思考を表現する能力、読む力は他人の思考を追跡する能力。使う脳の回路が違います。

コードも同じ構造です。書くときは自分の設計意図に沿って上から下へ流れるように書けます。読むときは、他人の設計意図を逆算しながら、コードの断片から全体像を組み立てる必要があります。

技術書で読解力を鍛える 3 つの方法

方法 1: サンプルコードを「先に読む」

多くの人は、技術書の説明文を読んでからサンプルコードを見ます。順序を逆にしてください。

まずサンプルコードだけを見て、「このコードは何をしているか」「なぜこの書き方をしているか」を自分なりに推測します。その後で説明文を読み、自分の推測と著者の意図を照合します。

推測が当たっていれば読解力がある証拠。外れていれば、自分の読み方の癖や盲点が見えます。この「推測 → 答え合わせ」のサイクルが、読解力を最も効率的に鍛えます。

方法 2: 設計本のリファクタリング例を追う

リファクタリングやデザインパターンの本には、「Before → After」のコード例が豊富に載っています。Before のコードを読んで「何が問題か」を自分で特定してから、著者の After を確認する。

リファクタリングの本は、コードの読解力を鍛える最高の教材です。Before のコードを読んで問題点を見抜く練習は、コードレビューの精度に直結します。

方法 3: 異なる著者の同じテーマを読み比べる

同じテーマ (たとえば「HTTP リクエストの処理」) を扱う 2 冊の本を用意し、それぞれのサンプルコードを読み比べます。同じ問題に対して、著者によって書き方が異なることに気づくはずです。

「なぜこの著者はコールバックを使い、あの著者は Promise を使ったのか」「なぜ一方はクラスで書き、他方は関数で書いたのか」。この比較が、コードの背後にある設計判断を読み取る力を養います。

読解力が上がると何が変わるか

コードレビューの質が変わる

表面的な指摘 (命名規則、フォーマット) だけでなく、設計意図のズレや暗黙の前提の見落としを指摘できるようになります。「このコードは動くけど、こういう前提が崩れたときに壊れる」という指摘ができるレビュアーは、チームにとって極めて貴重です。

デバッグが速くなる

バグの原因を追うとき、コードを読む速度と正確さが直接的に効いてきます。読解力が高い人は、スタックトレースから問題箇所を特定し、関連するコードを素早く読み解いて原因にたどり着けます。

オープンソースへの参加障壁が下がる

オープンソースプロジェクトに貢献する最大の障壁は、既存コードベースの理解です。読解力があれば、README とコードを読むだけでプロジェクトの構造を把握し、自分が手を入れるべき箇所を特定できます。

日常的にできる読解トレーニング

技術書以外でも、読解力は鍛えられます。

• GitHub の Trending リポジトリを毎週 1 つ選び、README とメインのソースファイルを 30 分だけ読む
• 自分が使っているライブラリのソースコードを、エラーが出たときに追ってみる
• 過去の自分が書いたコードを半年後に読み返し、「何を考えていたか」を思い出せるか試す

関連記事

• コードレビューが上手い人は何を読んでいるのか
• 写経を超える - 技術書のコードを自分のプロジェクトに応用する方法

まとめ

コードを書く力と読む力は別のスキルです。技術書のサンプルコードを「先に読んで推測する」習慣をつけるだけで、読解力は着実に向上します。読解力が上がれば、コードレビュー、デバッグ、オープンソース参加のすべてが楽になります。