种子工作

在面向对象的最早期，像我这样的面向对象倡导者将大量精力投入到为重用辩护。早期我们谈论的是类的重用。然后我们发现，虽然在某些情况下重用单个类是有效的，但在其他情况下却并不奏效。因此我们开始使用可重用的框架，这让我们获得了部分构建的功能应用程序。

从技术角度来看，这种重用已经取得了成功——看看 Java 和 .NET（不仅仅是 OO——正如 CPAN 所示）等环境提供的庞大库就知道了。但尤其是在业务方面，这种重用并没有那么快出现。在技术方面，许多人认为他们所使用的许多框架对于他们的目的来说过于复杂，而这种复杂性阻碍了这些框架的实用性。

迈克尔·菲瑟斯的一篇最近的博客文章深入探讨了这个问题，由此产生的讨论提出了一个替代概念——种子工作。框架应该是一个半成品的应用程序，你可以通过受控的方式对其进行扩展以提供你需要的功能。种子工作是一些最小的功能，你可以根据自己的需要对其进行修改。当然，这意味着你无法获得种子工作的通用更新，一旦你对其进行扩展，你就拥有了它。这是一种许多人（包括我自己）所嘲笑的复制粘贴重用。

也许我不应该如此轻蔑。框架和库在经过充分完善后非常有效。但获得一个好的框架非常困难。种子工作不如一个好的框架有用，但更容易创建和使用。重点不在于它们是否理想，而在于它们是否有用。

即使是成熟的重用也常常会成为问题。我们还没有真正弄清楚如何处理按不同时间表升级的共享库。我们都对微软的 DLL 地狱感到抱怨。就在本周，我发现我的 RedHat 系统在尝试安装一些软件时卡住了，发现我的版本依赖关系都乱了套（那一天就浪费了半天时间）。也许 .NET 中的版本控制系统会解决这个问题，但到目前为止，即使是好人也很容易被困住。

我发现，在应用程序内部进行重用（或避免重复）至关重要。但在应用程序之间进行重用要困难得多，主要是因为应用程序边界本质上是一种社会建构。这进一步证明了可重用的框架比我们想象的要困难得多，也进一步证明了我们应该考虑不太完美的替代方案——比如种子工作。