技術書の読み方として勘違いしていた、たった一つの事

http://d.hatena.ne.jp/higepon/20090129/1233212684 を見ながら、ふと、思い出したのでメモ。タイトルは、前述記事にならってつけてみました……本題の個人的に勘違いしていた事なのですが、それは、「技術書も小説のように、最初から最後まで、順番に読み進めていくもの」と思っていた事でした。

まずは第1章から第4章までを、じっくりと読まれることをお勧めします。次にカタログ部分をざっと読むようにします。最初はどこに何が書かれているかを大体知っていれば十分です。詳細について把握する必要はありません。実際にリファクタリングを行う必要が生じたときに、あらためて読む方が有効です。カタログは参照用の書き方なので、一度に読むのは大変だからです。

リファクタリング―プログラムの体質改善テクニック(p.xviii)

私自身は、かつては「読書と言えば小説を読む事」と言う意識で育った人と言う事もあってか、はじめに技術書を読み始めた時は、技術書の 1 ページ目から最後まで(頑張って理解しようとしながら)通して読む事をやろうとしていました。しかし、この方法だと、途中で自分の理解力が追い付かなくなる等でやる気を失い、結局、宝の持ち腐れ(積読本)が頻発する事となりました。

この状態から一歩前進できたのは、自分である程度まとまったプログラムを書くようになり、それに伴って問題にぶつかる頻度も増えてきた頃でした。自分で実際に問題にぶち当たってから技術書を読み直してみると、「何故、そう言う事をやろうとしているのか」と言う動機部分が肌で実感できるようになり、以前よりもそこに書いている内容がスムーズに理解できるようになったのです。この習慣が身に付いたきっかけの一つとして、その頃によくC++ライブラリクイックリファレンスと言う辞書的な技術書を(辞書を引く感覚で)読んでいた事も影響したのかなと思います。

モノにもよりますが、1 冊の技術書に記載されている内容と言うのはかなり膨大で、よほど該当分野に精通している状態でなければ初見で理解できる内容はたかが知れているのだろうと思います。それにも関わらず「通し読みで全部理解してやるぜ!」的な情熱で挑むと、大抵、その鼻をへし折られる結果となります。

また、技術書に書かれている内容は多くの場合いくつかのサブテーマが設定されており、途中の内容をすっ飛ばして読んでも該当部分を理解するのに大きな支障はないような構造になっています。したがって、上記にもあるように、初見時は導入的な章を読んだら後は各サブテーマの概要(最悪、タイトルだけでも良いか)だけを覚えて(脳内インデックス化)、詳細な内容の把握・理解は実際に問題にぶち当たってからに先延ばしするのが、結果として効率良く技術書を読み進めていけるのかなと現時点では感じています。

……と言う事を書こうかと思ったら、2 年前にほぼ同じ事を書いていました。引用している部分まで完全一致していたのは、我ながら少し驚きました。

広告を非表示にする