前车之覆，后车之鉴

——开源项目经验谈

（本文发表于《程序员》2005年第2期）

随着开源文化的日益普及，“参与开源”似乎也变成了一种时尚。一时间，似乎大家都乐于把自己的代码拿出来分享了。就在新年前夕，我的一位老朋友、一位向来对开源嗤之以鼻的 J2EE 架构师竟然也发布了一个开源的 J2EE 应用框架（姑且称之为“ X 框架”），不得不令我惊叹开源文化的影响力之强大。

可惜开源并非免费的午餐，把源码公开就意味着要承受众目睽睽的审视。仅仅几天之后，国内几位资深的 J2EE 架构师就得出一个结论：细看之下， X 框架不管从哪个角度都只能算一个失败的开源项目。究竟是什么原因让一个良好的愿望最终只能得到一个失败的结果？本文便以 X 框架为例，点评初涉开源的项目领导者常犯的一些错误，指出投身开源应当遵循的一些原则，为后来的开源爱好者扫清些许障碍。

成熟度

打开 X 框架在 SourceForge 的项目站点，我们立刻可以看到：在“ Development Status ”一栏赫然写着“ 5 – Production/Stable ”。也就是说，作者认为 X 框架已经成熟稳定，可以交付用户使用。那么，现在对其进行评估便不应该有为时过早之嫌。可是， X 框架真的已经做好准备了吗？

打开从 SourceForge 下载的 X 框架的源码包，笔者不禁大吃一惊：压缩包里真的 只有源码 ——编译、运行整个项目所需的库文件全都不在其中。从作者自己的论坛得知，该项目需要依赖 JBoss 、 JDOM 、 Castor 、 Hibernate 等诸多开源项目，笔者只好自己动手下载了这些项目，好一番折腾总算是在 Eclipse 中成功编译了整个项目。

不需要对开源文化有多么深刻的了解，只要曾经用过一些主流的开源产品，你就应该知道：一个开源软件至少应该同时提供源码发布包和二进制发布包，源码包中至少应该有所有必需的依赖库文件（或者把依赖库单独打包发布）、完整的单元测试用例（对于 Java 项目通常是 Junit 测试套件）、以及执行编译构建的脚本（对于 Java 项目通常是 Ant 脚本或者 Maven 脚本），但这些内容在 X 框架的发布包中全都不见踪影。用户如果想要使用这个框架，就必须像笔者一样手工下载所有的依赖库，然后手工完成编译和构建，而且构建完成之后也无从知晓其中是否有错误存在（因为没有单元测试）。这样的发布形式，算得上是“ Production/Stable ”吗？

开源必读：便捷构建 开源软件应该提供最便捷的构建方式，让用户可以只输入一条命令就完成整个项目的编译、构建和测试，并得到可运行的二进制程序。对于 Java 项目，这通常意味着提供完整的 JUnit 测试套件和 Ant 脚本。你的潜在用户可能会在一天之内试用所有类似的开源软件，如果一个软件需要他用半天时间才能完成构建、而且还无从验证正确性、无从着手编写他自己的测试用例，这个软件很可能在第一时间被扔到墙角。

从 SourceForge 的项目页面可以看到， X 框架的授权协议是 Apache License V2.0 （ APL ）。然而在它的发布包中，笔者没有看到任何形式的正式授权协议文本。众所周知， SourceForge 的项目描述是可以随时修改的（ X 框架本身的授权协议就曾经是 GPL ），如果发布包中没有一份正式的授权协议文本，一旦作者修改了 SourceForge 的项目描述，用户又该到哪里去寻找证据支持自己的合法使用呢？

在 X 框架的源码中，大部分源文件在开始处加上了 APL 的授权声明，但有一部分源码很是令人担心。例如 UtilCache 这个类，开始处没有任何授权声明，而 JavaDoc 中则这样声明作者信息：

@author      <a href="mailto:jonesde@ ofbiz.org ">David E. Jones</a>

也就是说，这个类的源码来自另一个开源项目 Ofbiz 。值得一提的是， Ofbiz 一直是“商业开源”的倡导者，它的授权协议相当严格。凡是使用 Ofbiz 源码，必须将它的授权协议一并全文复制。像 X 框架这样复制 Ofbiz 源码、却删掉了授权协议的行为，实际上已经构成了对 Ofbiz 的侵权。

另外，作者打包用的压缩格式是 RAR ，而这个压缩格式对于商业用户是收费的。对于一个希望在商业项目中应用的框架项目来说，选择这样一个压缩格式实在算不得明智。而且笔者在源码包中还看到了好几个 .jbx 文件，这是 JBuilder 的项目描述文件。把这些 JBuilder 专用的文件放在源码包中，又怎能让那些买不起或是不想买 JBuilder 的用户放心呢？更何况，出于朋友的关心，笔者还不得不担心 X 框架的作者是否会收到 Borland 公司的律师信呢。

开源必读：授权先行 在启动一个开源项目时，第一件大事就是要确定自己的授权协议，并在最醒目的地方用最正式的方式向所有人声明——当然，在此之前你必须首先了解各种开源授权协议。譬如说， GPL （ Linux 采用的授权协议）要求在软件之上的扩展和衍生也必须继承 GPL ，因此这种协议对软件的商业化应用很不友好；相反， APL 则允许用户将软件的扩展产物私有化，便于商业应用，却不利于开发者社群的发展。作为一个开源项目的领导者，对于各种授权协议的利弊是不可不知的。 除了源码本身的授权协议之外，软件需要使用的类库、 IDE 、解压工具等等都需要考虑授权问题。开源绝对不仅仅意味着“免费使用”，开源社群的人们有着更加强烈的版权意识和法律意识。如果你的开源软件会给用户带来潜在的法律麻烦，它离着被抛弃的命运也就不远了。

可以看到，不管从法律的角度还是从发布形式的角度， X 框架都远够不上“ Production/Stable ”的水准——说实在的，以它的成熟度，顶多只能算是一个尚未计划周全的开源项目。虽然作者在自己的网站上大肆宣传，但作为一个潜在的用户，我不得不冷静地说：即便 X 框架的技术真的能够吸引我，但它远未成熟的项目形态决定了它根本无法在任何有实际意义的项目中运用。要让商业用户对它产生兴趣，作者需要做的工作还很多。

我刚才说“即便 X 框架的技术真的能够吸引我”，这算得上是一个合理的假设吗？下面，就让我们进入这个被作者寄予厚望的框架内部，看看它的技术水平吧。

整体架构

在 X 框架的宣传页面上，我们看到了这样的宣传词：

X 框架解决了以往 J2EE 开发存在的诸多问题： EJB 难用、 J2EE 层次复杂、 DTO 太乱、 Struts 绕人、缓存难做性能低等。 X 框架是 Aop/Ico [ 注：应为“ IoC ”，此处疑似笔误 ] 的实现，优异的缓存性能是其优点。

下面是 X 框架的整体架构图：

可以看到，在作者推荐的架构中， EJB 被作为业务逻辑实现的场所，而 POJO 被用于实现 Façade 。这是一个好的技术架构吗？笔者曾在一篇 Blog 中这样评价它 [1] ：

让我们先回想一下，使用 EJB 的理由是什么？常见的答案有：可分布的业务对象；声明性的基础设施服务（例如事务管理）。那么，如果在 EJB 的上面再加上一 层 POJO 的 Façade ，显然你不能再使用 EJB 的基础设施了，因为完整的业务操作（也就是事务边界）将位于 POJO Façade 的方法这里，所以你必须重新 —— 以声明性的方式 —— 实现事务管理、安全性管理、 remoting 、缓存等基础设施服务。换句话说，你失去了 session bean 的一半好处。另一方面，“可分布的业务对象”也不复存在，因为 POJO 本身是不能 —— 像 EJB 那样 —— 分布的，这样你又失去了 session bean 的另一半好处。

继续回想，使用基于 POJO 的轻量级架构的理由是什么？常见的答案有：易于测试；便于移植；“开发 - 发布”周期短。而如果仅仅把 POJO 作为一层 Façade ，把业务逻辑放在下面的 EJB ，那么你仍然无法轻易地测试业务逻辑，移植自然也无从谈起了，并且每次修改 EJB 之后必须忍受漫长的发布周期。 即便是仅仅把 EJB 作为 O/R mapping ，而不是业务逻辑的居所，你最多只能通过 DAO 封装获得比较好的业务可测性，但“修改 - 发布”的周期仍然很长，因为仍然有 entity bean 存在。也就是说，即使是往最好的方面来说，这个架构至少损失了轻量级架构的一半优点。

作为一个总结， X 框架即便是在使用得最恰当的情况下，它仍然不具备轻量级架构的全部优点，至少会对小步前进的敏捷开发造成损害（因为 EJB 的存在），并且没有 Spring 框架已经实现的基础设施（例如事务管理、 remoting 等），必须重新发明这些轮子；另一方面，它也不具备 EJB 的任何优点， EJB 的声明性基础设施、可分布业务对象等能力它全都不能利用。因此，可以简单地总结说， X 框架是一个这样的架构： 它结合了 EJB 和轻量级架构两者各自的短处，却抛弃了两者各自的长处 。

在不得不使用 EJB 的时候，一种常见的架构模式是：用 session bean 作为 Façade ，用 POJO 实现可移植、可测试的业务逻辑。这种模式可以结合 EJB 和 POJO 两者的长处。而 X 框架推荐的架构模式，虽然乍看起来也是依葫芦画瓢，效果却恰恰相反，正可谓是“取其糟粕、去其精华”。

开源必读：架构必须正确 在开源软件的初始阶段，功能可以不完善，代码可以不漂亮，但架构思路必须是正确的。即使你没有完美的实现，参与开源的其他人可以帮助你；但如果架构思路有严重失误，谁都帮不了你。从近两年容器项目的更迭就可以看出端倪： PicoContainer 本身只有 20 个类、数百行代码，但它有清晰而优雅的架构，因此有很多人为它贡献外围的功能； Avalon 容器尽管提供了完备的功能，但架构的落伍迫使 Apache 基金会只能将其全盘废弃。 所以如果你有志于启动一个开源项目（尤其是框架性的项目），务必先把架构思路拿出来给整个社群讨论。只要大家都认可你的架构，你就有机会得到很多的帮助；反之，恐怕你就只能得到无尽的嘲讽了。

技术细节

既然整体架构已经无甚可取之处，那么 X 框架的实现是否又像它所宣称的那样，能够解决诸多问题呢？既然 X 框架号称是“ AOP/IoC 的实现”，我们就选中这两项技术，看看它们在 X 框架中的实现和应用情况。

IoC

X 框架宣称自己是一个“基于 IoC 的应用框架”。按照定义，框架本身就具有“业务代码不调用框架，框架调用业务代码”的特性，因此从广义上来说，所有的框架必然是基于 IoC 模式的。所以，在框架这里，“基于 IoC ”通常是特指“对象依赖关系的管理和组装基于 IoC ”，也就是 Martin Fowler 所说的 Dependency Injection 模式 [2] ：由容器统一管理组件的创建和组装，组件本身不包含依赖查找的逻辑。那么， X 框架实现 IoC 的情况又如何呢？

我们很快找到了 ContainerWrapper 这个接口，其中指定了一个 POJO 容器核心应该具备的主要功能：

public interface ContainerWrapper {

  public void registerChild(String name);

  public void register(String name, Class className);

  public void register(String name, Class className, Parameter[] parameters);

  public void register(String name, Object instance);

  public void start();

  public void stop();

  public Collection getAllInstances();

  public Object lookup(String name);

}

在这个接口的默认实现 DefaultContainerWrapper 中，这些功能被转发给 PicoContainer 的对应方法。也就是说， X 框架本身并没有实现组件容器的功能，这部分功能将被转发给其他的 IoC 组件容器（例如 PicoContainer 、 Spring 或 HiveMind 等）来实现。在 ContainerWrapper 接口的注释中，我们看到了一句颇可玩味的话：

/**

  * 封装了 Container ，解耦具体应用系统和 PicoContainer 关系。

了解 IoC 容器的读者应该知道，在使用 PicoContainer 或 Spring 等容器时，绝大多数 POJO 组件并不需要对容器有任何依赖：它们只需要是最普通的 JavaBean ，只需要实现自己的业务接口。既然对容器没有依赖，自然也不需要“解耦”。至于极少数需要获得生命周期回调、因此不得不依赖容器的组件，让它们依赖 PicoContainer 和依赖 X 框架难道有什么区别吗？更何况， PicoContainer 是一个比 X 框架更成熟、更流行的框架，为什么用户应该选择 X 框架这么一个不那么成熟、不那么流行的框架夹在中间来“解耦”呢？

不管怎么说，至少我们可以看到： X 框架提供了组件容器的核心功能。那么， IoC （或者说， Dependency Injection ）在 X 框架中的应用又怎么样呢？众所周知，引入 IoC 容器的目标就是要消除应用程序中泛滥的工厂（包括 Service Locator ），由容器统一管理组件的创建和组装。遗憾的是，不论在框架内部还是在示例应用中，我们仍然看到了大量的工厂和 Service Locator 。例如作者引以为傲的缓存部分，具体的缓存策略（即 Cache 接口的实现对象）就是由 CacheFactory 负责创建的，并且使用的实现类还是硬编码在工厂内部：

  public   CacheFactory() {

cache = new LRUCache();

也就是说，如果用户需要改变缓存策略，就必须修改 CacheFactory 的源代码——请注意，这是一个 X 框架内部的类，用户不应该、也没有能力去修改它。换句话说，用户实际上根本无法改变缓存策略。既然如此，那这个 CacheFactory 又有什么用呢？

开源必读：开放 -封闭原则 开源软件应该遵守开放 - 封闭原则（ Open-Close Principle ， OCP ）：对 扩展 开放，对 修改 封闭。如果你希望为用户提供任何灵活性，必须让用户以扩展（例如派生子类或配置文件）的方式使用，不能要求（甚至不能允许）用户修改源代码。如果一项灵活性必须通过修改源码才能获得，那么它对于用户就毫无意义。

在示例应用中，我们同样没有看到 IoC 的身影。例如 JdbcDAO 需要使用数据源（即 DataSource 对象），它就在构造子中通过 Service Locator 主动获取这个对象：

  public JdbcDAO() {

      ServiceLocator sl = new ServiceLocator();

      dataSource = (DataSource) sl.getDataSource(JNDINames.DATASOURCE);

同样的情况也出现在 JdbcDAO 的使用者那里。也就是说，虽然 X 框架提供了组件容器的功能，却没有（至少是目前没有）利用它的依赖注入能力，仅仅把它作为一个“大工厂”来使用。这是对 IoC 容器的一种典型的误用：用这种方式使用容器，不仅没有获得“自动管理依赖关系”的能力，而且也失去了普通 Service Locator “强类型检查”的优点，又是一个“取其糟粕、去其精华”的设计。

开源必读：了解你自己 当你决定要在开源软件中使用某项技术时，请确定你了解它的利弊和用法。如果仅仅为了给自己的软件贴上“基于 xx 技术”的标签而使用一种自己不熟悉的技术，往往只会给你的项目带来负面的影响。

AOP

在 X 框架的源码包中，我们找到了符合 AOP-Alliance API 的一些拦截器，例如用于实现缓存的 CacheInterceptor 。尽管——毫不意外地——没有找到如何将这些拦截器织入（ weave in ）的逻辑或配置文件，但我们毕竟可以相信：这里的确有 AOP 的身影。可是，甫一深入这个“基于 AOP 的缓存机制”内部，笔者却又发现了更多的问题。

单从 CacheInterceptor 的实现来看，这是一个最简单、也最常见的缓存拦截器。它拦截所有业务方法的调用，并针对每次方法调用执行下列逻辑：

    IF 需要缓存

       key = ( 根据方法签名生成 key);

       IF (cache.get(key) == null)

           value = ( 实际调用被拦截方法 );

            cache.put(key, value);

       RETURN (cache.get(key));

    ELSE

       RETURN ( 实际调用被拦截方法 );

看上去很好，基于 AOP 的缓存实现就应该这么做……可是，清除缓存的逻辑在哪里？如果我们把业务方法分为“读方法”和“写方法”两种，那么这个拦截器实际上只照顾了“读方法”的情况。而“写方法”被调用时会改变业务对象的状态，因此必须将其操作的业务对象从缓存中清除出去，但这部分逻辑在 CacheInterceptor 中压根不见踪影。如果缓存内容不能及时清理的话，用户从缓存中取出的信息岂不是完全错误的吗？

被惊出一身冷汗之后，笔者好歹还是从几个 Struts action （也就是调用 POJO Façade 的 client 代码）中找到了清除缓存的逻辑。原来 X 框架所谓“基于 AOP 的缓存机制”只实现了一条腿：“把数据放入缓存”和“从缓存中取数据”的逻辑确实用拦截器实现了，但“如何清除失效数据”的逻辑还得散布在所有的客户代码中。 AOP 原本就是为了把缓存这类横切性（ crosscutting ）的基础设施逻辑集中到一个模块管理，像 X 框架的这个缓存实现，不仅横切性的代码仍然四下散布，连缓存逻辑的相关性和概念完整性都被打破了，岂不是弄巧成拙么？

开源必读：言而有信 如果你在宣传词中承诺了一项特性，请务必在你的软件中完整地实现它。不要仅仅提供一个半吊子的实现，更不要让你的任何承诺放空。如果你没有把握做好一件事，就不要承诺它。不仅对于开源软件，对于任何软件开发，这都是应该记住的原则。

更有趣的是， X 框架的作者要求领域模型对象继承 Model 基类，并声称这是为了缓存的需要——事实也的确如此： CacheInterceptor 只能处理 Model 的子对象。但只要对缓存部分的实现稍加分析就会发现，这一要求完全是作者凭空加上的：用于缓存对象的 Cache 接口允许放入任何 Object ；而 Model 尽管提供了 setModified() 、 setCacheable() 等用于管理缓存逻辑的方法，却没有任何代码调用它们。换句话说，即便我们修改 CacheInterceptor ，使其可以缓存任何 Object ，对 X 框架目前的功能也不会有任何影响。既然如此，又为什么要给用户凭空加上这一层限制呢？

退一万步说，即使我们认为 X 框架今后会用 Model 的方法来管理缓存逻辑，这个限制仍然是理由不足的。毕竟，目前 X 框架还仅仅提供了缓存这一项基础设施（ infrastructure ）而已。如果所有基础设施都用“继承一个基类”的套路来实现，当它真正提供企业级应用所需的所有基础设施时， Model 类岂不是要变得硕大无朋？用户的领域对象岂不是再也无法移植到这个框架之外？况且，“由领域对象判断自己是否需要缓存”的思路本身也是错误的：如果不仅要缓存领域对象，还要缓存 String 、 Integer 等简单对象，该怎么办？如果同一个领域对象在不同的方法中需要不同的缓存策略，又该怎么办？ X 框架的设计让领域对象背负了太多的责任，而这些责任原本应该是通过 AOP 转移到 aspect 中的。在 X 框架这里， AOP 根本没有发挥它应有的效用。

开源必读：避免绑定 开源软件（尤其是框架类软件）应该尽量避免对你的用户造成绑定。能够在 POJO 上实现的功能，就不要强迫用户实现你的接口；能够通过接口实现的功能，就不要强迫用户继承你的基类。尤其是 Java 语言只允许单根继承，一旦要求用户的类继承框架基类，那么前者就无法再继承其他任何基类，这是一种非常严重的绑定，不论用户和框架设计者都应当极力避免。

写在最后

看完这篇多少有些尖刻的批评，恐怕读者难免要怪责我“不厚道”——毕竟，糟糕的开源软件堪比恒河沙数，为什么偏要选中 X 框架大加挞伐呢？在此，我要给各位读者、各位有志于开源的程序员一个最后、却是最重要的建议：

开源必读：切忌好大喜功 开源是一件长期而艰巨的工作，对于只能用业余时间参与的我们更是如此。做开源务必脚踏实地，做出产品首先在小圈子里内部讨论，然后逐渐扩大宣传的圈子。切勿吹大牛、放卫星，把“未来的愿景”当作“今天的承诺”来说——因为一旦工作忙起来，谁都不敢保证这个愿景到哪天才能实现。 国人还有个爱好：凡事喜欢赶个年节“献礼”，或是给自己绑上个“民族软件”的旗号，这更是开源的大忌。凡是做过政府项目的程序员，想必都对“国庆献礼”、“新年献礼”之类事情烦不胜烦，轮到自己做开源项目时，又何苦把自己套进这个怪圈里呢？当然，如果你的开源项目原本就是做给某些官老爷看的，那又另当别论。

所以，我的这位朋友怕也不能怪我刻薄：要不是他紧赶着拿出个远未完善的版本“新年献礼”，要不是他提前放出“ AOP/IoC ”的卫星，要不是他妄称这个框架“代表民族软件水平”，或许我还会夸他的代码颇有可看之处呢。有一句大家都熟悉的老话，笔者私以为所有投身开源者颇可借鉴，在此与诸位共勉：

长得丑不是你的错……

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=276486