オルタナティブ・ブログ > An Agile Way >

アジャイルに行こう!

Designing a framework in an "open" way (オープンなフレームワーク設計)

»

"Beautiful Code" を読んでいます。

いいですねー。カーニハンやベントレー(『プログラマの打ち明け話』、『珠玉のプログラミング』、『プログラミングの設計と着想』など、昔ファンでした)の文章をひさしぶりに読みました。まだまだ、プログラミングにもわくわくすることが一杯ありますね。

ぼくが最も感動したは、Michael Feather ("Working Effectively with Legacy Code"の著者)の

"Framework for Integrated Test: Beauty Through Fragility"(英語GoogleBook全文)

です。コーディング(プログラム設計)に関する Ward Cuninngham の逸話はいくつもあります。November メソッドの話、400行の Perl で書かれた初版 Wiki の話、などなど。

今回は、Web ブラウザでテストが行える FIT というテスティングフレームワークの「設計」についてです。

通常のフレームワーク設計の前提ルール(属性はprivate、ホットスポットを用意し、そこをオーバーライドさせることで、アプリケーションに制御を渡す)を越えて、あたらしい可能性とコードとしてのシンプルさを両立させている例です。ほとんどの属性を public にしていますし、主要クラスはたった3つ。HTMLに限って問題を解決することで、こんなに美しいコードになる。決して他人が簡単には到達できない設計に見えました。属性やメソッドの名前付けも単刀直入でうまく読めます。class Parse の中に more と parts という同じParse型の public 属性を持たせて、そこにコンストラクタで table を含む HTML をパースして入れてしまいます。S式に分解しているような感じです。おかげで、

Parse last() { return more == null ? this : more.last() }

みたいな、Lispっぽいというか、そんな自然なコードがぽんぽん書ける。

Rails のような、問題を限定してシンプルさを獲得して、余りあるパワーを出すフレームワークが、Javaでもこんな風にできるんだ。。。。と驚きと、そして、こんな設計をする勇気が湧きました。

そして、最後には、普通APIというとリリース後に変更の影響がでるために、できるだけ public な部分を絞るのに対し、FITでは、ほとんどオープンにしていること。そして、それが、プログラミングという活動のソーシャル性と関わっていること(分かってくれる人には、そのまま提供したほうがよい)、それが Beauty を作り出していることへの指摘があります。

このコード、ぜひみなさんにも味わって欲しいなぁ。良いコード、良い設計とは何か(何だったか)、という問いをもう一度考えられると思います。

推奨リンク:

Comment(0)