この業界にいると、技術書と呼ばれる書籍に接する機会が増えてきます。以前にプログラミング業界の良書を紹介する事がブームになった時に 全てのプログラマが読むべき本 まとめ と言うまとめ記事を作ってみたりもしましたが、目を通しておいた方が良い書籍として、ざっと挙げられているものだけでも結構な数になります。良書が多いのは良い事なのですが、読む本の候補が多くなるにつれて、ともすれば勢いで買ってみたが結局読まない「積読」が増えてしまうと言う現実に遭遇したりして、「技術書との効果的な読み方」、あるいは「技術書とのよい付き合い方」みたいな事で頭を悩ませる機会も多くなるかと思います。
個人的な経験則なのですが、技術書と言われる類の本は、小説や物語のように「最初から最後まで順に通して読む」のようなスタイルを貫くと大抵失敗する(途中で読むのを挫折する、または、最後まで読破はできたが内容が頭の中に入っていない)と言う印象があります。
実際にリファクタリングを行おうとする場合 まずは第 1 章から第 4 章までを、じっくり読まれることをお勧めします。次にカタログ部分をざっと読むようにします。最初はどこに何が書かれてあるかを大体知っていれば十分です。詳細について把握する必要はありません。実際にリファクタリングを行う必要が生じたときに、あらためて読む方が有効です。カタログは参照用の書き方なので、一度に読むのは大変だからです。
リファクタリング―プログラムの体質改善テクニック (p. xviii)
技術書の場合、上記のように「最初は各章の概要だけを把握しておいて、実際の作業で困った時に該当の章を読む」と言う使い方をするとうまくいきやすいように思います。
経験を体系化し整理する役割
私の経験上で最も印象深いのは、Modern C++ Design と言う書籍です。この書籍は内容が難しい書籍としてよく取り上げられたりした(する?)のですが、私自身も手にしてからしばらくは、読んでも筆者が何を伝えようとしているのかがよく分からないと言う状況が続きました。
その状況から脱却したきっかけは、CLX C++ Libraries と言う C++ のクラスライブラリを作成した事でした。このライブラリを作った目的の 7 割くらいは自分の C++ の学習のためだったのですが*1、このライブラリを作成するに当たって、様々な実装上の困難に遭遇し、また既存のライブラリがどのようにその困難を解決しているのかを実装コードを目で追いながら模索しました。そして、その後に先ほどの書籍を読むと、そこに書かかれている内容が驚くほど「よく分かる」と肌で実感できたのを覚えています。
デザインパターンなどの書籍を読む時にも実感するのですが、この類の技術書の役割は「自らの経験を体系化し、きちんと整理してくれる事」なのかなと思います。そのため、内容を読む前に実際に困難に遭遇し、あるいは似たような解決策を模索した後の方が、より効果的に自分の知識として吸収しやすくなります。
ただ、あまり自分の経験を重視しすぎると特定の範囲(自分の仕事に密接に関連している部分等)以外のものに疎くなってしまうのも事実で、その辺りのバランスは難しいところです。プログラム一つを取っても、適度に新たなもの(プログラミング言語、パラダイム、ライブラリ、etc)に挑戦して困難を味わい、書籍を読むことでそう言った困難を体系付けて自分の知識のバリエーションを増やすと言うサイクルを、ある程度は続けていきたいものです。
*1:そのため、他のライブラリで既に見かけるような物の「車輪の再発明」的なコードも数多く含まれていたりします。