ソフトウェアを読む技術

小説の読み方って本は結構ある。どのように小説を読んだら良いかってなことが書いてある。最近特にいろいろ出ている。もちろん、小説の書き方って本もたくさん出ている。
ここで、当たり前だけど、小説を書く人より読む人のほうが、だんぜん多いんだけど、読み方と書き方で、どっちが多く出版されているかといったら、多分書き方のほうだと思う。たぶん。

で、翻って本題。ソフトウェアの書き方の本はいっぱい出ている。どのようにプログラムを作成するかっていう本。で、まあ、基本的にはプログラムをどのように書くのか知る必要があるし、基礎知識がないとプログラムを理解することもできない。でも、仕事の中でプログラムを書く場合、新規に作成するよりも既存のプログラムを修正することのほうが、格段に多いと思う。日本は特に、受託開発のうち派生開発がほとんどではないかと、『「派生開発」を成功させるプロセス改善の技術と極意』で清水吉男さんもおっしゃっている。
で、そのときに最も必要になってくるのが、”他人のソースコードを読む技術”なんだけど、それについて書かれた本というのは、ほとんど見たことがない。しかし、仕事として一番必要なのは、ソフトウェアを書く技術よりも、ソフトウェアを読む技術ではないだろうか。

まあ、そうはいっても、本の読み方とソースコードの読み方ってのは非常に似ていて、本の読み方が多いに参考になるんだけど。でも、ソースコードって、オープンソースのようなものかサンプルのソースコードくらいしか世に出回ってなくて、難解なソースコードってまあ、世に大いに知らしめることもないんだけど。実務上は、そういう難解な（難しいことをしているんじゃなくて、何でこのような処理になるのかさっぱり理解できないってこと。単なる辻褄合わせだったりすることもある。）ソースコードに出会うことが多い。。。から、いかにソースコードを読むべきかって本もあってしかるべきだと思うんだけど。

で、まあ、そういう悪辣なソースコードを読みこなしてバグ修正とかできる能力と、小説を読み込んで批評することっていうのは本質において似ているんじゃないかと思うんだけど。だから、まあ、優れた批評家はデバッグも上手であるに違いないということが、いいたかったわけでもないんだけど。まあ、似ているなーと。