種子工程

在物件導向的早期，像我這樣的 OO 倡導者都非常重視重複利用的論點。早期，我們討論的是類別的重複利用。然後我們發現，重複利用個別類別雖然在某些情況下可行，但在其他情況下卻不太可行。因此，我們開始使用可重複利用的架構，這讓我們獲得了部分建構的功能應用程式。

在技術方面，這種重複利用已經成功了，只要看看 Java 和 .NET 等環境中提供的龐大函式庫（不只是 OO，CPAN 也證明了這一點）。但特別是在業務方面，這種重複利用並沒有那麼快出現。在技術方面，許多人認為他們處理的許多架構過於複雜，無法達到他們的目的，而這種複雜性會阻礙這些架構的實用性。

Michael Feathers 的一篇近期網誌深入探討了這個問題，討論結果提出了另一個概念：種子工程。架構應該是部分建構的應用程式，您可以以受控的方式擴充它，以提供您需要的功能。種子工程是一些最小的功能，您可以隨意修改它們以獲得您需要的功能。當然，這表示您無法取得種子工程的常見更新，一旦您擴充它，您就擁有它了。這是我，包括我在內，許多人所嘲笑的複製貼上式重複利用。

也許我不應該這麼輕蔑。當架構和函式庫成熟時，它們會非常好用。但要獲得一個好的架構非常困難。種子工程不如好的架構有用，但更容易建立和使用。重點不在於它們是否理想，而在於它們是否實用。

即使是成熟的重複利用，也常常會造成問題。我們仍然沒有真正弄清楚如何處理在不同時程升級的共用函式庫。我們都對 Microsoft 的 DLL 地獄抱怨過。就在這週，我發現當我嘗試安裝一些軟體時，我的 RedHat 系統卡住了，而且發現我的版本相依性都搞砸了（浪費了半天時間）。也許 .NET 中的版本控制系統會解決這個問題，但到目前為止，即使是優秀的人員也很容易遇到問題。

我發現應用程式內的重複利用（或避免重複）至關重要。但跨應用程式的重複利用困難得多，主要是因為應用程式邊界主要是一種社會建構。這進一步證明了可重複利用的架構比我們想像的困難得多，而且我們應該考慮不太完美的替代方案，例如種子工程。