シリーズ第３回なんですけども、ここでちょっとコーヒーブレークで歴史を振り返りましょう。

結局、「コードの読みすさ」というものは、

プログラムの実行とは直接関わらないが、プログラムの全体的な把握を容易にする説明記述を、いかに合理的に追加するか？

ということになります。こういう視点は実は結構前からありまして、その創始者は例によって、ドン・クヌースです。クヌースは「文芸的プログラミング」という名前でアイデアを表現しています。

我々はプログラム作成における伝統的な態度を変更すべきである。すなわち、計算機に何をすべきかを命じることが我々の主要関心事であるという妄想を捨て去り、人間に我々が計算機に何をさせたがっているかを説明することにむしろ傾注すべきである。（クヌース「文芸的プログラミング」より、有澤誠訳）

言いますねえ！ 「どう動くか」を「コンピュータに指示」することは、本当は全然重要ではなくて、「人間に理解させる」ことの方がずっと重要だ、とクヌースは過激に主張しているわけです。あ、クヌースがこのやり方を実践したのは TeX の開発の中でですから、実際には 1980年代に公にしているわけです（例の TeX Book の出版...ということになりますか）。ですから、随分と昔から、「プログラムとコメントとを合体させて、人間に判りやすいように記述する」というアイデアはあるものです。

ですから、クヌースは自分のことを「コンピュータに指示を出すプログラマ」ではなくて、「人間を相手にした随筆家」だとしています。

文芸的プログラミングの実践者は随筆家とも見なされよう。その関心は主として解説と文体の卓越にある。著作者は手に辞典を持ち、注意深く変数に名前を付け、各変数の意味を説明する。彼は理解可能なプログラムを作ろうと努力し、諸概念を人間に一番わかりやすい順番で導入し、形式的、非形式的方法をないまぜて、お互いが効果を強めあうようにするであろう。　

....ここらへん、昔すごく憧れたものです。TeX Book なんて、「読み物兼プログラム」で出版されていたわけですから...

とはいえ、この発想はかなり時代に先んじていたわけです。しかし、「ドキュメントがソースとシンクロしないのは、それを別々にメンテしているからだ！」というもっともな理由から、Java では最初から javadoc が付いていた...こともあって、最初から「ソースがドキュメントを含み、ソースからドキュメントを抽出して Web ページとして構築できる」という格好になったわけです。クヌースでは「ドキュメントの中にソースがある」でしたが、これが「ソースの中にドキュメントがある」という、今一般的なかたちに逆転しているわけですね。

で、この javadoc のアイデアの元って何だろう？というと、やはりメイヤーにありそうです。実際には「ドキュメントとソースをシンクロさせるのには、それが１つのファイルに合体している必要がどうしてもある」というだけでは足りず、それを「ドキュメントの view」「ソースの view」という感じで、自動的に view を切り替えて出力し、しかもそれが「情報隠蔽」を実現した格好になっている、という発想がポイントのように感じます。メイヤーだと、

その代わりに、モジュールの中にドキュメントを含めるべきなのである。この方法では、ソフトウェアは１つの製品でありながら、複数の見え方（view）をサポートするようになる。１つの見え方はコンパイルと実行に適した見え方で、ソースコード全体である。また別の見え方は個々のモジュールの抽象的なインターフェイスドキュメントで、ソフトウェアを開発する人がモジュールそのものの内部を知らずに顧客モジュールを書けるようにするためのもので、情報隠蔽の原則に従っている。（「オブジェクト指向入門第２版」邦訳p70）

と、この自己文書化をＯＯＰの中にきっちりと位置づけて考えています。でしかも、実際にはメイヤーの場合、事前条件・事後条件といった表明で記述される制約は、現実的に「インターフェイスの記述」になるものですから、これも自己文書化の対象とならなければなりません。ですから、メイヤーが Eiffel に対する javadoc として作った short では、この表明記述を抽出してドキュメントとする機能を備えているわけです。

残念なことに、Java の表明機能（assert）は機能を限定された実装です。ですから、javadoc と assert が連携して、自動でインターフェイスの制約を javadoc に盛り込む...なんてことはできません。これが出来たら、少しは Java の assert も普及するのでは...とも思いますね！

とはいえ、以前にも書いたことですが、メイヤーの「契約によるプログラミング」とXPの「テストファースト」とは、かなり相通ずる側面があります。これを考えてみると、JUnit のテストクラスを、うまくテスト対象クラスと結びつけて、JUnit の書き方を工夫して、「JUnit の javadoc コメント」をうまく「テスト対象クラスのインターフェイス制約」として取り込むような仕組み、というのを考えてみるのも有益かもしれません....意外にテストクラスの javadoc というのはサボりがちですが、実はこれは

javadoc で管理し、テスト計画書が javadoc で出力できるようにする

のが当然ベストです。そう考えてみると、テストクラスの javadoc というのは実は意外な潜在的な活用の可能性を多く秘めている存在かもしれません。