コードを「書く力」と「読む力」は別物 - 読解力を鍛える技術書の使い方
この記事は約 6 分で読めます。
書けるけど読めない問題
自分でコードを書くのは得意なのに、他人のコードを読むのが苦手。オープンソースのコードを追おうとしても、すぐに迷子になる。コードレビューで「何をやっているか」は分かるが「なぜそう書いたか」が読み取れない。
同じ悩みを聞くことは珍しくないのに、「コードの読み方」を体系的に学ぶ機会は限られています。入門書も研修も、課題を書き上げることを到達点に置きがちです。他人のコードを読む訓練は、どうしても後回しになりやすいところがあります。
書く力と読む力が別物である理由
自然言語と同じです。日本語で文章を書ける人が、全員、法律文書や学術論文をスラスラ読めるわけではありません。書く力は自分の思考を表現する能力で、読む力は他人の思考を追跡する能力です。同じ言語を扱っていても、作業の向きが逆になります。
コードも同じ構造です。書くときは自分の設計意図に沿って上から下へ流れるように書けます。読むときは、他人の設計意図を逆算しながら、コードの断片から全体像を組み立てる必要があります。
技術書で読解力を鍛える 3 つの方法
方法 1: サンプルコードを「先に読む」
多くの人は、技術書の説明文を読んでからサンプルコードを見ます。順序を逆にしてください。
まずサンプルコードだけを見て、「このコードは何をしているか」「なぜこの書き方をしているか」を自分なりに推測します。その後で説明文を読み、自分の推測と著者の意図を照合します。
推測が当たっていれば、その書き方の型は自分の中にすでにあります。外れていれば、自分の読み方の癖や盲点が見えます。この「推測 → 答え合わせ」のサイクルは、読み方のずれを毎回はっきりさせてくれるので、説明文から順に読み進めるより手応えが残ります。
方法 2: 設計本のリファクタリング例を追う
リファクタリングやデザインパターンの本には、「Before → After」のコード例が豊富に載っています。Before のコードを読んで「何が問題か」を自分で特定してから、著者の After を確認します。
リファクタリングの本は、問題のあるコードと改善後のコードが対で並ぶという点で、読解の練習に向いています。Before から問題点を見抜く作業は、コードレビューで手を動かす前にやっていることとほぼ同じです。ただし本の Before は説明のために問題点が一つに絞られています。実際のコードでは複数の問題が絡むので、練習と同じ手際で見抜けなくても当然だと考えておいてください。
方法 3: 異なる著者の同じテーマを読み比べる
同じテーマ (たとえば「HTTP リクエストの処理」) を扱う 2 冊の本を用意し、それぞれのサンプルコードを読み比べます。同じ問題に対して、著者によって書き方が異なることに気づくはずです。
「なぜこの著者はコールバックを使い、あの著者は Promise を使ったのか」「なぜ一方はクラスで書き、他方は関数で書いたのか」。この比較が、コードの背後にある設計判断を読み取る力を養います。
読解力が上がると何が変わるか
コードレビューの質が変わる
表面的な指摘 (命名規則、フォーマット) だけでなく、設計意図のズレや暗黙の前提の見落としを指摘できるようになります。「このコードは動くけど、こういう前提が崩れたときに壊れる」という指摘ができるレビュアーは、チームにとって極めて貴重です。
デバッグが速くなる
バグの原因を追うとき、コードを読む速度と正確さが直接的に効いてきます。読解力が高い人は、スタックトレースから問題箇所を特定し、関連するコードを素早く読み解いて原因にたどり着けます。
オープンソースへの参加障壁が下がる
オープンソースプロジェクトに貢献しようとして手が止まる理由の多くは、既存のコードベースを読み解けないことです。読解力があれば、README とコードを追うところから始めて、プロジェクトの構造と自分が手を入れられそうな箇所を絞り込んでいけます。
日常的にできる読解トレーニング
技術書以外でも、読解力は鍛えられます。
- GitHub の Trending リポジトリを毎週 1 つ選び、README とメインのソースファイルを 30 分だけ読む
- 自分が使っているライブラリのソースコードを、エラーが出たときに追ってみる
- 過去の自分が書いたコードを半年後に読み返し、「何を考えていたか」を思い出せるか試す
関連記事
まとめ
コードを書く力と読む力は別のスキルです。技術書のサンプルコードを「先に読んで推測する」習慣は、特別な教材を用意しなくても今日から始められる訓練です。読む力が付いてくると、コードレビューやデバッグ、オープンソースへの参加で最初につまずく部分が減っていきます。
この記事は役に立ちましたか?
関連用語
関連記事
写経を超える - 技術書のコードを自分のプロジェクトに応用する方法
技術書のサンプルコードを写経するだけでは実力は伸びません。書籍のコードを自分のプロジェクトに応用し、実務で使える力に変える 5 つのステップを解説します。
本を読んでもすぐにコードが書けなくて当たり前
本を 1 冊読み終えたのに、いざコードを書こうとすると手が動かない。これは普通のことです。読書とコーディングの間にあるギャップと、その埋め方を解説します。
コードレビューが上手い人は何を読んでいるのか
的確なコードレビューができる人は、指摘を裏づける語彙と判断基準を持っています。レビュー力を支える 3 つの読書領域と、レビューに直結する知識の身につけ方を解説します。
コードを書かずに技術力を上げる休日の過ごし方
休日にコードを書く気力がないとき、それでも技術力を伸ばす方法があります。読書、設計スケッチ、技術記事の執筆など、キーボードに触れずにスキルアップする具体的な過ごし方。
技術書のレビュアーになる方法 - 出版前の本を読む特権
技術書のレビュアー (査読者) になるための 3 つのルートと、良いレビューの書き方、レビュアーとしての心構えを紹介します。
コードを書かない日に読む本
休日や有給休暇など、コードを書かない日にこそ読むべき本があります。実装から離れた日に読むと効果が高い本のジャンルと、その理由を解説します。