覚えることの大切さ

私の著書のひなた先生(→ http://d.hatena.ne.jp/yaneurao/20081114 )の売上がパソコン関連書籍のなかで6位だった。

『このコンピュータ書がすごい！2009年版』(→ http://d.hatena.ne.jp/onering/20090110/1231582043 )なんかでも取り上げていただいたので、その影響かも知れない。 いま考えてみるに、「ひなた先生」で失敗だったと思うのは、読みやすくしすぎたということだ。会話形式だから、さくさく読める。すぐに読み終わる。なんとなくわかったつもりになる。そんな読み方をしても何も得るものがないのに、と思う。 この本の最初のほうで、「二分法でデバッグ」というのが出てくる。簡単に言えば、バグのありそうな箇所を、半分にぶった切って再現するか調べていけば、logオーダーでバグの箇所に到達できるというデバッグの原理だ。思うにデバッグをしていく上で最も重要な原理である。 熟練者ならずとも無意識のうちにやっていると思うが、これを言語化するといままで考えていなかったことがいろいろ見えてくる。 半分ずつと言っても何を基準に半分なのか？ソースレベルでの行数か？バイナリレベルでの実行命令数か？実行時の物理的な時間か？それとも自分の感覚的なものか？

仮にソースの行数が半分になるようにするとして、半分も失うとプログラムは正常に機能しないが、それでバグを再現させることが出来るのか？ 本当はそういうことを立ち止まってひとつひとつゆっくりと考えて欲しい。さっと読み終わって欲しくない。そして、自分がそのとき理解したことを記憶として覚えておいて欲しい。デバッグは実践することが大切なのだから、自分が同じような状況に遭遇したときにすぐにデバッグの方針が頭に浮かぶようでなければならない。 つまり、「ある状況に対して、それを解決する何通りかの方針がパターンとして瞬時に頭に浮かぶ」ようにする訓練をしなくてはならない。デバッグに限ったことではないが、この訓練をしなくては身についたとは言えない。読みやすく理解しやすい本ほど、読者はこの訓練を怠る。 だから、自分が書いたプログラムのバグを見つけた時には次の二つを常に考えて欲しい。 ・そのバグは何故起こったのか？ ・そのバグをどうやればもっと早く見つけることが出来たか？ そのためのヒントは、「ひなた先生」にたくさんある。「この本を読んでもデバッグが速くなるかは疑問」だとか言ってる人は、内容は理解できているのだろうから本は古本屋にでも売っちゃっていいので、是非この訓練をしていただきたい。