Rui-san が Gauche のコードがを上から下まで読んだのは勉強になったという話をしており、遅ればせながら自分も本腰を入れて読むコードが欲しくなった。そこで読んでみたいプロジェクトを書き出してみたものの収まりが悪い。なぜそれを読みたいのか、まずは自分の中にある基準を書き出してみることにする。重要度順。

Code Quality: まず良いデザイン、良いコードであること。要するに一般的な意味でのコード品質が高いこと。汚いコードを読むのは辛い。大半の C++ コードはダメ。MySQL, MongoDB あたりは脱落。Mesos, WebKit とかもうーむ...

Problem Maturity: よく考え抜かれ、よく研究された問題を解いていること。教科書的な問題には多くの人が時間をかけた研究の成果が詰まっている。難しい問題を、洗練された方法をたくさん使って解いている。大げさに言えば人類の英知がある。OS や言語処理系、信号処理、データ圧縮、人工知能などなど。

Suppleness: コードがデザインを、デザインが問題への理解や意見を直接に反映していること。問題への理解がコードに反映されておらず、オラーっと勢いで書いてしまってるコードというのは結構ある。理想的にはコードを読めば問題と答えを理解できると良い。Code quality みたいなものかもしれないけど、アーキテクチャのまともさに近い。抽象度高め。古い問題の焼き直し系はそれなりにあてはまる。たとえば LLVM とかディティールはひどいけど大まかなデザインは教科書的。

Relevance: 知りたいと思っている分野の問題であること。ジャンルとして興味のあるものを読みたい。たとえば自分は人工知能とかあんまし興味ない。何が好きかは人によってまちまちだから意味ない指標かもしれないけれど、他人の勧めと自分の興味のバランスは要るよね。

Foreign-ness: よく知らない問題であること。どうせなら新鮮な発見がほしい。自分だと今更別のブラウザを読む気にはならない。VM も何度か読んだことあるので気が乗らない。

Self contained-ness: 自己完結する度合いが高いこと。いろいろなライブラリを繋ぎ合わせて作ったものは、本題が依存先ライブラリの中にあったりして拍子抜けする。あちこち読むのも大変でまとまりがないから、できれば読み物として閉じていてほしい。Gauche や Go は多分この点でよくできてる。そうでなくても古いものは自己完結する率が高い気がする。

Size: 大きすぎないこと。でかいと読むのが大変。そしてでかいコードはその大半が、動作には必要だけれど読むに値しないものだったりする。コードの中で問題にとって本質的な部分の割合が高いほど望ましい。Linux のコードなんて大半はドライバなわけだし、「ドライバ」みたいに綺麗にわかれてないだけで世の中の巨大なコードは大半がそういう枝葉末節からできている。ブラウザだと HTML の個々の要素の実装とか読む題材としてはどうでもいいけど量は多い。そういうコードがダメという話ではない。読むものはノイズが少ないほどいいというだけで。

Age: 古すぎないこと。今更 C 言語とかよみたくない。あとおっさんが読んだものをあとから読むのは癪だし上から目線でなんか言われたりして不愉快。Emacs とか絶対読みたくない。K&R ですらない。

Theoretical Complexity: 背景にある理論が難しすぎないこと。すごい難しい数学が背後にあり、その数式をコードにおとしたような問題は結構ある。背後の理論がわかってないと何もわからない。それを勉強するのも含めてコードリーティングという面はあるけれど、自分には機械学習とかわかる気がしない。数学が苦手という個人的な事情ゆえか・・・。

Familiarity: 自分が使っているものであること。触ったことがあり、動作を知ってるものの方が理解しやすい。自分の場合この理由でサーバサイドが辛い。もっとウェブアプリとか書いてるならいいんだろうけど。

Standalone-ness: ライブラリやフレームワークよりはシステムやアプリケーションであること。強い主張というよりは個人的な好み。依存するものが多いのがいまいちなのの裏返しで、 依存されてはじめて意味があるというのも読み物として自己完結度が低い気がする。

これらを完全に満たすものはないだろうけれど、ただぼんやり列挙して gut feeling に従うよりは納得のいく形で読む題材を選べる気もする。具体的なプロジェクトについてはこれから考える。