シードワーク

http://martinfowler.com/bliki/Seedwork.html

オブジェクト指向黎明期、私のようなオブジェクト指向提唱者は、再利用性を支持する議論に注力していた。早くからクラスの再利用について話していた。それから、独立したクラスを再利用することは、いくつかのケースではうまくいくが、他の場所ではあまり動かないということが分かった。そのため、再利用性のあるフレームワークに関わるようになっていく。フレームワークとは、機能面からいえば半完成アプリケーションである。

技術的な側面では、こういった再利用はうまくいった。Javaや.NETなどの巨大なライブラリを見れば分かる（オブジェクト指向ではないが、CPANも）。しかし、特にビジネス側では、こういった再利用は急速に出現しなかった。技術側の多くの人が、フレームワークの多くは、目的を果たすには複雑すぎると感じたのだ。この複雑さがこれらの利便性を排除していた。

Michael Feathers が最近のweblogでこの問題を掘り下げた。議論の結論は、もうひとつの意見に行き着いた。シードワークだ。フレームワークの場合、自分がやりたいことを実現するには決まった制御方法に従って拡張を行う、いわば生焼けアプリケーションになっていた。シードワークは最低限の機能がついていて、いかようにも変更可能である。いちど変更すれば、あなたのものである。私も含め、多くの人が笑うコピペ再利用の一種だ。

でもこれは軽蔑すべきことではないかもしれない。フレームワークとライブラリは十分加味されていればよく動く。しかし、よいフレームワークになるのは大変難しい。シードワークはよいフレームワークほど便利ではないかもしれないが、作ったり使ったりするのがより簡単である。どちらが理想的かという問題ではない。ただ、どちらが使いやすいかという問題である。

成熟した再利用でさえも問題になりうる。異なったスケジュールでアップデートされた共有ライブラリをどう扱うかまだよく分かっていない。みんなマイクロソフトDLL地獄にうめき声をあげている。ちょうど今週、いくつかのソフトウェアをインストールしていて、私のレッドハットが動かなくなってしまい、最新の注意を払いながらバージョンの依存性を見つけ出したのさ。（半日をこれで無駄にしちゃった）.NETのバージョニングシステムならばこの問題を解決してくれるかもしれないけど、扱い方がわかってる人でさえ、使いやすいとはいえないね。

アプリケーション内の再利用（もしくは重複排除）は重要である。しかし、アプリケーション間の再利用はより難しい。そもそもアプリケーション境界は社会的構成だからである。再利用フレームワークは想像よりずっと大変なのは明らかだ。そして、シードワークのような不完全な代替案を考える意味があるだろう。