轻量级开发是一个很大的主题，开发人员经常提到这个术语，但却很难讲明它的意思。本文是一系列讲述轻量级开发的文章中的首篇，介绍了该技术背后的核心原则及原理。

1990 年，我发现了白水漂流并深深爱上了它。我们哪怕是经过最小的湍流，都会留一个人在湍流尾部，两个人在岸边用绳索拽着。我们认为这可以防止任何糟糕的事情发生。虽然看起来一切尽在掌握，只是有些不太实际。我们还学会了从船舱观察普通的湍流，并设法互相协作。对于大多数危险的湍流，我们花费了更多的时间来保障安全，但是只有少数情况下，这些措施才起到重大的作用。

在漂流过程中，使用一种起源于东南部湍急河流的轻量级策略，为我节省了时间，使我可以划得更远，玩得更开心，而无需过多考虑安全问题。在业务领域，轻量级开发让您可以按时完工，积极响应客户，从而节省时间和金钱。

在本系列的文章中，我关注于轻量级开发（曾经有太多含义的术语）的基础。本篇文章作为第一篇，为读者打好基础，同时对轻量级开发做出定义。后面的文章由浅入深地讲述从过程到原则最后到工具的知识。我也将在更高的级别上关注原理和架构的实现，并且提供具体实现的代码。

本系列面向没有经过太多轻量级开发的读者。如果您已使用了两年的 Spring 轻量级容器和敏捷过程，您可能会收获更多。如果您在传统的开发过程中使用 Enterprise JavaBeans™（EJB），但想要转向轻量级开发，那么本系列就是为您准备的。

我更多地是想在这场席卷整个 Java™ 技术社区的潮流中，做一些自己的贡献。轻量级 这个噱头为诸如 Spring 和 Pico 这样的容器增添了几分优雅。并且，一些源自轻量级过程的技术，如自动化单元测试，现在也渗透到了很多开发工作室中。

戳穿针对轻量级开发的谣言
“轻量级开发”通常与一套开发方法、框架和设计原理一起使用。

• 轻量级方法 包括敏捷过程，例如极限编程（XP）和 Scrum。它们强调开发中测试第一，积极调动客户和重构。
• 轻量级框架 鼓励人们使用简单原始的 Java 对象（POJO）编程，而不是类似 EJB 的重量级面向组件模型。
• 轻量级设计模式 使您可以在对象和集成服务之间进行松散耦合，而无需艰苦地编写业务逻辑或领域模型。

当我们研究这些思想和技术时，您将会学到更多关于它们的知识。但是首先让我们戳穿一些谣言。

谣言：轻量级开发只是一种“玩具”技术。
许多开发工具，如 Microsoft® Visual Basic 或 PHP，它们通常不能驾驭或管理大型企业项目，因此得到了“玩具”的称号。像 Spring 和 Hebernate 这样的轻量级技术就常常因此而黯淡。实际上，大多数轻量级技术用于了企业开发，因为其他技术都使我们非常失望。Spring 框架就是作为代替 EJB 的一种轻量级技术。同样，XP 方法吸收改进了企业中的错误设置。我在获得 Jolt 大奖的 Better, Faster, Lighter Java 一书中，为大家讲述了有关成功部署在我的客户站点上的一些工具的信息，客户有一些是财富 500 强中的公司。轻量级技术在企业领域内，正在蓬勃发展着。

谣言：轻量级开发策略构建的是“玩具”。
也许您更倾向于相信轻量级开发只对构建“玩具”应用程序有益。而您的目标是精确地满足客户的需求。让我们首先明确一下：轻量级技术完全可以构建这种规模的应用程序。实际上，这种巨大的反差经常发生，因为只有简单、简洁、无状态的设计才能使基础设施更好地工作。

谣言：轻量级过程使您忽视规范。
在轻量级开发中，您需要认真地规划并与客户磋商需求。您必须构建严格的自动化单元测试，以优化重构。当放弃变更时，仍可以保持程序完整。而且，测试用例失败或变更引发错误时，自动化构建会通知您。轻量级开发必须比其他技术更加注意规范，但这种规范源于不同方面。

我认为这种开发风格超越了单一的技术或过程。如果您想轻松一些，那么需要选择使它易于工作的原则、过程和技术。

原则
该说的也说了，该做的也做了，您现在需要决定哪些需要重视，并据此制定决策。如果我觉得客户被误导或漠不关心，我通常会首先帮助他们建立核心原则。下面的列表是一个不错的起点：

• 争取简单性。这种观念应该渗入到您所有的工作中。您的过程应该刚好生成足够完成工作的工件。开发人员应该尽量使用最简单的方法解决问题。您的工具应该使您构建一个清晰、简洁的解决方案。
• 修补漏洞。许多开发方法可能不鼓励在过程中进行重构或变更，因为这些行为不直接用于产生客户代码。轻量级开发要求可以自由地修补太复杂或充斥 bug 的代码。您需要为它做出预算。
• 自动化单元测试。您应该优先编写测试用例。您可能还没有在测试第一的开发中成功过，但测试会间接给您带来重构代码的便利。我以后会进一步讲述：广泛的单元测试改善您的客户体验，并提高代码的设计水平，这是因为它强迫您解耦联系过于紧密的代码。
• 使用短开发周期并积极调动客户参与其中。许多顶级的软件工作室通过剔除不必要的工件来简化开发周期。如果您已经顺利得到客户的参与，那么很多的功能规范会变得越来越没必要。客户会很满意这种交互，并感激您的短周期开发，因为这稳步提高了客户的业务价值。

这些原则并不能完全包含您的技术抉择和开发过程，但它有利于您描述开发体验。如果经理也了解并遵循这些原则，开发人员就不至于做出无效技术选择，或者开发一些不必要的工件。确立原则后，就该规划一个有效过程了。

过程
紧凑、快速的开发过程通常从敏捷开发方法 当中得到灵感。然而，这些方法并不针对每个人。如果您有一个大型团队，并且没有实际访问客户或合适的代理人，那么传统方法更适合您一些。但多数项目都有小团队 —— 不超过 12 个人，他们可以充分访问客户，以灵活使用这种方法。通常，敏捷开发包括下列原则：

• 专注现场客户和代码，而不是其他设计技巧。您可以使用其他技巧，但只在它们对您确实有益的情况下。本过程不需要它。
• 简化您需要的文档。为了需要，宁可使用电子表格中的一行来描述，也不使用令人困惑的用例图。
• 只做足以完成工作的设计工作。不要对设计或性能过分忧心忡忡，使自己陷入绝境。
• 为了开发，努力进行简化并保证至少每天都集成您所构建的程序，必要时进行重构。
• 自动化测试。

即使您工作在传统的机构，您也可以利用已裁减的开发过程。技巧是推广原则 而不是方法。推广极限编程管理器 —— 或其他冠以极限 的东西，这可能会很艰难。但推广类似单元测试的原则通常更有意义。实际上，我的许多客户使用这种技术同敏捷开发过程一起为保守的机构服务，但他们的老板丝毫不知道有什么发生了改变。

用修辞手法描述一下这种技术。原则 是重拳出击的轻量级思想。过程是重量级的，实现起来将会很困难。

技术
我已经概述了大多数轻量级开发人员需要了解的设计原理，以及利用这些原理的重要开源技术。

依赖注入
最新一代容器称为轻量级容器，它们使用一个共同设计原理：依赖注入。 对这个简单思想来说，这是一个复杂的术语。依赖注入让您将对象和它所依赖的东西交给第三方。然后第三方创建所有对象并将它们绑在一起。比方说，称为 myDao 的数据访问对象需要一个称为 ds 的数据源。那么该容器会一同创建它们，并设置一个属性：

myDao = new Dao();
ds = new DataSource();
myDao.setDataSource(ds);

当然，不创建这种第三方汇编程序的话，您也可以使用框架来做其他附加的工作（如提供配置支持）。Spring 框架、Pico 和 HiveMind 就扮演了这个角色。其他像 JavaServer Faces(JSF) 框架也利用了依赖注入。

面向对象编程
使用面向对象编程（AOP），您可以编写通用的功能性模块（称为方面） —— 例如，日志、事务、安全或持久性。AOP 使您可以将这些方面联系到 POJO，然后指定一个时间点（如方法开始时或产生异常时）和另一个需要联系的方面。例如，您可能想要创建一个外观事务对象。您可以在调用方法时将 TransactionBegin 方面关联到外观方法。然后在产生异常时将 RollBack 方面关联到外观的异常。最后，在方法结束时将 Commit 方面关联到外观的方法。您在配置中完成这些工作，而不是通过编写代码。依靠这种能力，您可以创建一个简单的 POJO 事务、安全或远程访问。

您现在已经得到了关于 POJO 的声明性事务，这对企业应用程序非常有用。使用这些工具，您可以完全放弃 EJB，或者最小化它的作用。而这正是轻量级组件所要做的。

透明持久性
持久性也是建立在较简单的编程模型之上。透明持久性框架通过配置而不是编写代码，来使您为应用程序添加持久性。因为大多数应用程序是面向对象的，并且访问一个关系数据库，所以一些专家断言，我们最终将进入对象关系映射的时代。我目前发现的顶级持久性解决方案是 SolarMetric 的 Kodo JDO 和 Hibernate（参阅 参考资料）。在后面的文章中我将详细比较这些解决方案。其他轻量级解决方案，例如 iBATIS 和 Active Record 设计模式，根本不会试图进行对象关系映射。

结束语
在轻量级开发中，您基本上可以：

• 合并过程、技术和原理。
• 优先选择较简单的技术。
• 在一个稳固、轻量级的基础上，进行构建。
• 尽量争取最可能的透明性。
• 使用您可以利用的技术，如依赖注入和 AOP。

一定要明白，无论技术还是过程都不能完整定义轻量级开发。它是一个包罗万象的概念。伴随本系列的文章，您将看到对轻量级技术和原理的各种各样的讨论。我将首先关注开源框架，并着重讲述轻量级容器。后面的文章，我会讨论保守公司内的轻量级方法实现，甚至还有一些超越了 Java 技术的替代方案。我非常喜欢这个系列的文章，希望您也一样。