ソースコードの読み方

ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。

ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？

閑話休題。

ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようになった。これはいいことである。時代の進歩といっても差し支えない。

カーネル読書会ではその道の優れたプログラマにお話を聞くが、わたしは時々、どうやってデバッグをしているかとか、どうやってコードを読むかというような質問をする。暗黙知としてハッカーがもっているものを言語化してもらってどうにか形式知にしたいと思っている。

しかし、そうは言ってもまだまだ職人芸の世界で、なかなか優れたプログラマの技法というのが形式知化されているとは言いがたい。定石を集めたいところである。

ユメのチカラでは下記のエントリを記した。

コードを読むな、理解しろ
http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html

これはoprofileを利用してrubyをハックした事例である。コードを読むのは端から端まで直列で読んでいたらいくら時間があっても読みきれない。コードを読むには、コードを読まないテクニックが必要でそれを紹介した。ブックマークやトラックバックもいっぱいいただいた。

トラブルシューティングの実際
http://blog.miraclelinux.com/yume/2006/10/post_5353.html
実際にあった問題を、ソースコードの観点から理解するという事例である。使っている道具立てはgrep/findなどなど標準的なものばかりだ。別段トリッキーなことをしているわけではない。包丁とフライパンだけで料理を作るようなものである。職人は道具を使いこなす。その技を見てほしい。

なぜソースコードを読むのか？
http://blog.miraclelinux.com/yume/2006/08/post_3771.html
そのものずばりの話題について記した1999年ころの記事である。大聖堂のプログラマであったわたしがオープンソースの潮流に触れその可能性にわくわくしていた感覚がある。「ソースコードを読む。その基礎的な技術がオープン・ソースの時代には最も必要とされているのである。」と断言しているが、その確信は今でもゆるぎない。

下記は大規模ソフトウェアの効率的な理解という観点で記した。ざっくり通しで読んでいただければ幸いである。

大規模ソフトウェアの効率的な理解
http://blog.miraclelinux.com/yume/2006/08/post_cae5.html
「OSSの時代こそ大規模ソフトウェアの実装の効率的な理解の方法論が求められている。企業が自分が作ったソフトウェアを自社のエンジニアに教育（OJT）するのと違って、OSSはそのような内部構造の教育コースがない。自分のすぐそばにコア開発者がいないので簡単に聞くことが難しい。
中略
その実践的な方法論についていろいろ議論していきたいと思う。」

大規模ソフトウェアの効率的な理解（その2）
http://blog.miraclelinux.com/yume/2006/08/2_2d39.html
ソフトウェアの規模を下記のように定義した。
    規模         行数
    小規模       10万行以内
    中規模       10万〜100万行程度
    大規模       100万行以上
ソフトウェアを構成する行数でおおざっぱにくくっている。あるいは開発に関与する人数によっても同様にくくれる。
    規模         人数
    小規模       10人以内
    中規模       10人〜100人程度
    大規模       100人以上

大規模ソフトウェアの効率的な理解（その3）
http://blog.miraclelinux.com/yume/2006/08/3_dc26.html
規模の把握。

大規模ソフトウェアの効率的な理解（その4）
http://blog.miraclelinux.com/yume/2006/08/4_4b7e.html
巨視的、微視的な理解という観点を提示している。

大規模ソフトウェアの効率的な理解（その5）
http://blog.miraclelinux.com/yume/2006/08/5_de60.html
「動的というのはソフトウェアを実行した時の挙動のことをさし、静的というのはソフトウェア(プログラム)の字面をさす。」
動的理解、静的理解という側面から解説した。

大規模ソフトウェアの効率的な理解（その6）、リグレッションテスト
http://blog.miraclelinux.com/yume/2006/08/6_570e.html
「OSSの実装も単にソースコードやドキュメントを整備するだけではなく、リグレッションテストをどれだけ充実するかという視点で議論、評価される時が来ているように感じる。よりOSSが大規模になり、修正が頻繁に求められるようになるとリグレッションテストが整備されているかいないかで、その変化に対する対応力が全然かわってくるのである。」

gdbの実践的使い方
http://blog.miraclelinux.com/yume/2006/09/post_fa59.html
gdbをデバッガとしてしか利用していないとしたらその威力の10%も利用していない。gdbはソースコードを読むためのツールである。「gdbはソースコードの理解を助ける偉大なツールなのである。」

gdb/xemacs/cscopeの使い方
http://blog.miraclelinux.com/yume/2006/09/gdbxemacscscope_e0da.html
「プログラムの状態は変数の値の変化によって変化していくわけだが、変数は、宣言され、値を代入され、参照されるなどして利用される。」

おまけ：
カーネル読書会とよしおかの野望
http://blog.miraclelinux.com/yume/2006/07/post_69b1.html
「ソースコードを読むことは楽しい。そういうと、多くの人は怪訝な顔をする。無理強いはしないしするつもりもないし、もちろんできないのであるが、ソースコードを読むことが楽しいということを少しでも多くの人に伝えたくて、あるいはそのような同好の士を発掘したく、ぼそぼそと続けている。」

本日のエントリーはソースコードの読み方という観点からまとめてみたが、テストの仕方、デバッグの仕方、性能問題の発見とチューニングなどなどについてもいつかは記していきたいと思う。コメント、トラックバックなどをお待ちする。

追記：
はてなブックマークを多数の方に付けていただいている。（これを書いている時点で100を越えている。）どうもありがとうございます。下記も参考になると思う。
大規模ソフトウェアをgdbを利用して微視的視点から理解をする
http://blog.miraclelinux.com/yume/2006/09/post_8096.html
gdbを利用して、どのようにソースコードを理解するか事例を紹介している。実際にあった事例なので、瑣末なめんどくさい事も含めて参考になると思う。現場はそのような瑣末なことがらにみちみちているのである。