シードワーク

オブジェクト指向の初期の段階において、私のようなオブジェクト指向 advocates は再利用を支持するために多くの注意を払っていました。当初、クラスの再利用について話していました。その後、個々のクラスの再利用は場合によっては機能するものの、他の場所ではあまり機能しないということがわかりました。そこで私たちは再利用可能なフレームワークに取り組み、機能的に部分的に構築されたアプリケーションを得ることができました。

技術的な面では、この種の再利用は成功しています。Java や .NET などの環境で利用できる大規模ライブラリ（CPAN が示すように、オブジェクト指向に限らず）を見ればわかります。しかし、特にビジネスの側面では、このような再利用はそれほどすぐに現れません。また、技術的な側面では、多くの人が取り扱うフレームワークの多くが目的には複雑すぎて、この複雑さがこれらのものを有用にすることを妨げていると感じています。

マイケル・フェザーズによる最近のウェブログでこの問題を掘り下げたところ、議論の結果、代替的な概念であるシードワークが生まれました。フレームワークとは、制御された方法で拡張して必要なものを提供する、部分的に構築されたアプリケーションのことです。シードワークは最小限の機能であり、必要なものを得るために好きなように変更することができます。もちろん、これはシードワークを成長させると、共通の更新プログラムを入手する方法はなく、自身のものになることを意味します。これは、私を含め多くの人が嘲笑する、コピーアンドペーストによる再利用の一種です。

私はそんなに軽蔑すべきではないのかもしれません。フレームワークとライブラリは十分に成熟していると、非常にうまく機能します。しかし、優れたフレームワークを得ることは非常に困難です。シードワークは優れたフレームワークほど有用ではありませんが、作成して使用するのは簡単です。問題は理想的かどうかではなく、単に有用かどうかです。

成熟した再利用でさえ、多くの場合問題になることがあります。異なるスケジュールでアップグレードされる共有ライブラリの処理方法がまだ完全に理解できていません。私たちは皆、Microsoft の DLL ハルを嘆いてきました。ほんの今週、ソフトウェアをインストールしようとしたときに RedHat システムが機能しなくなったことがわかり、すべてのバージョン依存関係がめちゃくちゃになっていることがわかりました（半日が無駄になりました）。NET のバージョン管理システムがこれを解決してくれるかもしれませんが、これまでのところ、優れた人々でさえ陥るのは簡単すぎます。

アプリケーション内での再利用（または重複の回避）は不可欠であることがわかりました。しかし、アプリケーション間での再利用は、アプリケーション境界は主に社会構造であるため、はるかに困難です。これは、再利用可能なフレームワークは私たちが考えるよりもはるかに困難であり、シードワークなどの完全ではない代替案を検討すべき理由がさらに多いことを示す証拠です。