种子作业

在面向对象很早的日子里，像我一样的 OO 倡导者将很多注意放到了支持重用。早前我们谈论了关于类的重用。然后我们发现，重用单独的类，它能在有些情况能工作得很好，但是在其他情况也工作得不好。因此我们进入了可重用的框架，它能获得我们内建的部分应用程序功能。

就技术而言，这种重用是成功的 — — 只是查看大型类库就能够重用了，比如 Java 和 .NET 黄金（并不只 OO — — 就像 CPAN 那个例子）。但在业务端，重用方面不会很快出现。技术方面，很多人觉得大量的框架对于他们的目的来说处理的非常复杂，这些复杂性反而远离了重用。

Michiael Feathers 最近的博客 提到了这个问题，讨论的结果是提出了另一个想法 — — 种子作业。一个框架应该是一个半成品应用程序，你要以自控的方式来拓展提供你自己想要的。种子作业是一些很小的功能，你可以根据需要来修改。当然这就是说没有方法能让你获取通用的更新种子作业，一旦你种植他，也就拥有了他。这是一种复制粘贴式的重用，对于很多人来说，也包括我。

也许我不应该如此轻视。在他们经验丰富时，框架和类库能工作的很好。但是得到一个好的框架是很难的。种子作业作为一个好框架来说不怎么有用，但是很容易创建和使用。关键是无论它们是否理想，而是只需要有用。

成熟的重用经常会成为问题。我们仍然没有真正明白怎么去处理在不同的调度上升级共享库。我们都抱怨微软的 DLL-hell。这周，我发现在我的红帽系统卡住了，当我试图安装一些软件时，发现我的版本依赖都混乱了（那浪费了我半天时间）。也许在 .NET 版本系统将会解决这个问题，但是迄今为止，即使是好人也容易被定住的。

我已经发现重用（避免复制）在应用程序是至关重要的。但是跨应用程序的重用很慢，因为应用程序边界是主要相关的结构。更多的证据证明可重用的框架要比我们想象的要难，并且有足够的原因，我们应该考虑那些不怎么完美的选择 — — 比如种子作业。

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