基于Spring＋Hibernate＋Eclipse进行敏捷Java开发(1)

【51CTO.com独家特稿】一、简介

本文与其它典型的Java文章有所不同，这主要体现在两个方面。首先，我们没有深入讨论有关于一些API或优秀工具的细节，而是提供了使用敏捷方法和普通Java对象（POJO）构建企业级Java应用程序的一个指南。其次，本文中涉及到大量的从概念到工程发布等多方面的基本内容。因此，为了简洁起见，本文中仅提供了极少的代码摘录；然而，本文还提供了一个基于Spring，Hibernate，Junit和Ant构建的完全可运行的示例时间表应用程序（并有相应的源代码）供您参考。

现在，让我们言归正传。

二、敏捷宣言

在2001年，17位软件专家(包括Martin Fowler，Kent Beck和Jon Kern)聚集到一起共同探讨有关软件开发的轻量级途径；最终，他们联合定义了术语“敏捷”并发出了“敏捷软件开发宣言”—为这些敏捷方法提供了一组参考值和原则。

术语“敏捷”中融入了大范围的多种方法；其中一些包括极限编程(XP)，Scrum，特征驱动开发，敏捷建模以及Crystal。而且，这其中的许多方法都倾向于至少包括过程和建模两个方面（因为它们经常联系在一起）；接下来，我们将逐一展开讨论。而有关敏捷宣言和各种敏捷方法的更多细节，请访问agilemanifesto.org和agilealliance.org网站。

三、敏捷过程

一种最容易理解的敏捷过程就是Scrum。尽管XP在整个敏捷社区似乎更为引人注目，但是它较之于Scrum要更复杂些。不过，这两者却是高度互补的，因为XP提供一组优秀的工程实践，而Scrum则更多地强调产品/工程管理。事实上，最近，我更倾向于推荐首先基于Scrum进行“敏捷”开发，然后每次添加一项XP实践，这是因为完全基于XP进行开发对于许多组织来说还有些太冒然，并且要求他们对于许多工程的开发要作好充分的思想准备。

那么，Scrum是如何工作的呢？很简单。我们只需提供相应于产品订货（BACKLOG）中的一个应用程序的新特征或改变请求的一个列表即可。在我们的示例应用程序TimeExpression中，这些包括：

◆按小时工资制的雇员能够签入到一个Web应用程序并且输入对于某一周他们每天的工作小时数。
◆该雇员的经理必须同意这个时间表。
◆在同意/否定了一个时间表之后，把通知发送给该雇员并指示该时间表的更新状态。
◆等等……

之后，我们只要按照最高优先级特征，把它们移动到一个sprint订货表中，并且通过一个月(或更短时间内)的反复工作来实现它们（称为“sprint”），并且继续这种以月为周期的sprint直到实现所有的特征。每一个sprint(或迭代)都包含完整的软件生命周期—也即：详细的要求/分析，设计，编码，单元/接受测试，以及成熟产品的发布。Scrum还建议，在每一个sprint的开始举行一次计划碰头会，而在该sprint的完成之时进行一次回顾来讨论已经取得的教训或在随后的sprint中要实现的特征。除此之外，我们还要举行每日一次的短暂碰头会（比如说，15分钟）来讨论工程的状态。图1描绘了这种Scrum过程。有关于Scrum的更多细节，请访问网站controlchaos.com。

图1：Scrum敏捷过程简要描绘

敏捷过程的一个普通主题就是迭代性开发。例如，尽管XP的工作就象Scrum一样工作，但是它使用了基于每周一次的迭代的季度发行的概念（如图2所示）。还该特征are提供in该表单of用户故事，典型地是由客户使用一到三行语句来描述一下相应的特征。我在此对XP的解释可能过分简化；其实，关于XP还有其它大量内容，例如结对编程（pair programming），共同讨论（sit together）与持续构建（continuous build）等。有关于XP的更多细节请访问网站extremeprogramming.org。

至此，我们已经简单分析了解了两种敏捷过程：Scrum和XP。这些内容极有助于收集用户特征请求并有助于整个工程管理。然而，作为开发者，我们需要把这些特征实现到应用程序中。因此，接下来，让我们了解一下敏捷建模技术，这可能有助于我们建立用户需求和编码之间的“桥接”。

图2：XP敏捷过程简要描绘

四、敏捷设计

根据来自thefreedictionary.com网站的定义，模型是“一种初步的作品，最终的产品将基于之进行制作……也用于测试或完善一个最终的产品。”因此，本文中我将使用“模型”一词来描述图表及其它人为绘制内容。

敏捷模型驱动开发

由Scott Ambler创建的敏捷模型驱动开发(AMDD)为进行有效的建模提供了指南。不是创建广泛的模型，AMDD推荐创建“足够好”的模型。我最喜欢的Scott的一句话就是“你的目标是构建一种共同的理解而不是编写一篇详细的文档。”

AMDD建议使用两种类型的模型：需求（requirements）和架构（architecture）。需求模型有域模型(参考图3)、用法模型（例如用户故事/用例，参考图4)以及UI模型(例如原型和流程图，分别参考图5和图6)等。

图3：域模型

图4：用法模型

图5：原型形式的UI模型

图6：流程图形式的UI模型

图7：架构模型中的自由形式（freeform）的模型

架构模型中可以包括一种自由形式的模型，如图7所示。

有关于AMDD并没有太多的资料可循，因为它仅为敏捷建模提供了最小的指南。有关于敏捷建模的更多细节，请访问网站agilemodeling.com。