敏捷开发以及开发人员与数据库管理员的联系

作者：Scott Ambler

现在数据库管理员应该用已在开发人员领域中采用的“敏捷”技巧来更新他们的技能

与以一种敏捷和渐进（重复并增加）的方式工作的现代开发人员不同，大多数数据库管理员趋向于以一种“串行”的方式工作。但随着面向服务应用程序 (SOA) 潜在地改变软件开发的特性，数据库管理员必须和它一起改变。

“敏捷”软件开发技巧的采用可能成为这个过程中的一个重要的因素。开发人员不仅使用了新的技术（如服务），而且他们还采用了新的开发技巧来提高他们的效率。这些技巧 — 极限编程、特性驱动的开发、测试驱动的开发和敏捷建模 — 在细节上各不相同，但它们的重点都在下面这几点上：

开发人员和数据库管理员之间的协同工作风格

支持敏捷软件开发的数据管理技巧（与传统的不支持敏捷软件开发的串行技巧相对而言）

反映现代环境现实的新型、灵活的开发工具。
在本专栏中，我将说明一些技巧，这些技巧鼓励在 SOA 开发项目期间在开发人员和数据库管理员之间建立密切的合作关系。您的工作方式上的一些简单的变化可以使您变成一个大家所需要的人物，而不是又一个被“忽略或忽视”的人物。

敏捷软件开发说明

敏捷软件开发 (ASD) 是一种面向人的协作方法，该方法专注于高价值的活动。敏捷应用程序开发人员一般以一种“渐进”（重复并增加）的方式工作，周期性地创建运作的软件。

敏捷宣言 (Agile Alliance 2001a) 定义了四个简单的价值声明，作为敏捷方法的基础：
个体和交互胜过过程和工具。人们组成团队来构建软件系统，为了实现这个目的，他们需要高效的合作 — 包括（但不限于）编程人员、测试人员、项目经理、建模人员和客户。工具和过程很重要，但它们没有高效的合作重要。

运作的软件胜过面面俱到的文档。当您问用户他们想要一份 50 页文档（说明您想要构建什么）还是软件本身时，您认为他们会挑哪一个？如果您能够快速地创建软件并经常可以为用户提供他们更喜欢的东西，难道这种工作方式不是更有意义吗？而且，我对用户能够通过复杂的技术框图 — 它们说明软件内部工作方式或提供软件用途的一个概括 — 来更容易得多地理解您开发的软件表示怀疑。文档有它的作用；如果写得适当，它对人们理解一个系统如何和为什么构建，以及如何利用这个系统进行工作是一个非常有价值的指导。不过，永远别忘了软件开发的主要目的是创建软件，而不是文档。否则，它将叫做文档开发，难道不是吗？

客户合作胜过合同谈判。与客户合作很难，但现实工作中您必须这么做。与他们签订合同很重要，但这并不能代替交流。成功的开发人员与客户密切合作，他们投入精力来了解客户需要什么，并且他们自始至终培训他们的客户。

响应变化胜过遵循计划。人们会因各种各样的原因改变他们最初的计划；随着工作的进展，他们对问题的理解和解决方案将发生变化。商务环境和底层的技术也会发生变化。有一个项目计划没什么错 —实际上，我怀疑会不会有一个项目没有计划。不过，一个项目计划必须是可塑的；也就是说，当情况变化或您的计划很快变得落后于事态发展时，必须能够灵活地修改它。如果变化是现实存在的，那么遵循一个反映实际情况的过程，而不是试图以一种通常效率低下和僵化的方式来勉强地控制变化难道不是很有意义吗？
经常指责敏捷应用程序开发人员没有在正式的软件过程上投入精力。相反：敏捷应用程序开发人员实际上的确使用开发工具并遵循软件过程，只是我们坚持使用能够增加价值的工具和专注于成功地交付软件的过程 — 这与专注于成功交付文档的完全僵化的过程相反。敏捷应用程序开发人员的确建模并编写文档，但我们专注于高价值的模型（其中许多模型在使用后就丢弃了）和简洁高效的文档。我们能够很好地管理变化；只是我们认为不必遵循一个麻烦而且僵化的过程来实现这个目的。

关于敏捷软件开发的重要事项之一是它不特指任何面向数据的开发特定类型。这里也不特指 Java、COBOL 或 web 服务 — 价值和原则是独立于技术的。不过，我的经验是数据管理社区的价值可以并且应该在敏捷工具包中反映出来。

这就是 Agile Data (AD) 方法的意义所在。它为敏捷的面向数据的开发定义了六个原则：
数据。数据是基于软件的系统的几个重要的方面之一；因此在每个开发项目中都要涉及到数据库管理员。不过别忘了，涉及对象技术、web 服务、组件和其它技术的问题也很重要。

企业问题。开发团队必须根据企业问题（如可持续的体系结构、标准和工具）进行考虑并相应地采取措施。

企业组。企业组的存在是为了培育企业资产并支持您机构中的其它组（如开发小组）。这些企业组应当以一种敏捷的方式进行工作，这种方式能够反映客户的期望和客户的工作方式。

唯一性。每个开发项目都是唯一的，它需要一种灵活的、为它的需求量身定制的方法。一个软件过程不能适合所有的情况，因此数据相对的重要性根据要解决的问题的特性而变化。有时，DBA 在一个项目中将起到关键的作用，而在某些时候只起到很小的支持作用。

团队合作。DBA 和开发人员必须合作以确保项目成功；企业的利益相关者不应该非得忍受由内部工作人员争吵而导致的效率低下。

平衡点。您应当积极努力地找到任何问题的平衡点，避免走极端，以找到能够使您的总体情况最好的折衷方案。例如，一个数据库只使用自然键 (natural key) 是一个极端，只使用替代键 (surrogate key) 是另一个极端，而大多数数据库都包含了两者 — 为什么人们还对这类问题争论不休？
AD 方法形成了原则基础，在这个基础上开发人员和 DBA 能够高效地合作。不过，光有原则还不够：您还需要可使用的技巧。让我们探讨一下使您能够用一种渐进的方法来进行数据库开发的技巧。

定义渐进式数据库开发

有这种可能吗？绝对可能，但您必须选择以这种方式工作。您还需要采用能够反映现代软件开发的现实的技巧：敏捷的模型驱动的开发、对象/关系映射、代码重构、测试驱动的开发和渐进式性能调整。

敏捷模型驱动的开发 (AMDD)

AMDD 是一种建模的方法，使用这种方法您能够创建高价值的敏捷模型，这种模型正好足够解决相关的问题。您不需要预先创建一个完整的模型；相反，您只需进行足够的建模工作，使您能够继续进展下去，然后让模型在将来继续发展。高效的开发人员创建模型来彻底全面地考虑“大问题”，然后使用其它的技巧（如 TDD 和重构）来解决详细设计的“小问题”。

例如，对开发人员而言，对一个 SOA 的高水平服务建模而不对构建服务所需的全部细节编写文档是很常见的。然后细节通过测试案例的开发而充实起来。这种方法的好处在于模型和测试都用得到最好的应用：使总体的设计和文档编制工作最少，同时确保系统完全得到测试。

在我看来，Oracle JDeveloper 10g 的一个主要的特性是对建模的支持。它利用统一建模语言 (UML) 来支持面向对象建模，并超越它包含了用户界面 (UI)、数据库和 XML 建模。AMDD 的原则之一是多模型，它提到：您需要了解大量的建模类型，以便您能够使用最适合于任务的模型。虽然 UML 是您的建模工具包的一个重要的部分，但不幸的是，它并不全面：特别是，它没有包含对您的 UI 或数据进行建模的标准方法。Oracle 做出了正确的举动，它扩展了建模特性，这些特性能够解决开发人员在这方面的需要。

Oracle JDeveloper 10g 通过 Struts Page Flow 编辑器利用用户界面流程建模来支持 UI 开发。这是为商务应用程序开发人员提供的一个关键的功能，因为它简化了基于 J2EE 的应用程序的创建。虽然 Struts 是一个优秀的框架，但它可能难于编码，因此我宁愿使用诸如 Struts Page Flow 编辑器之类的工具来简单地生成代码。（还有，我很懒。）

Oracle 还在 Oracle JDeveloper 10g 中通过增加 Database Modeler 工具为表的建模引进了 UML 数据建模方法 — 这是多年来我一直强烈支持的建模方法。为什么使用 UML 来创建数据模型而不是简单地使用经过时间考验的 Barker 符号？首先，UML 是开发人员可能都了解的一种标准，这使得您能够更容易地进行协作，因为你们共享了一种公共的建模语言。第二，这将是 UML 入门的一种好办法，并从而开辟新的职业机遇。

一个关键的特性是您能够容易地在您的模型和源代码之间来回转移，从而支持渐进式开发。它还支持 AMDD 的“用代码来证明”的实践：在屏幕上，每个模型看起来都好像能够工作，但在您用可运转的代码证明它之前，您永远不能确定这一点。

O/R 映射

对象/关系 (O/R) 映射是所有开发人员和数据库管理员都应该了解的另一种关键的技术。现代应用程序常常在前端使用对象技术（如 Java 或 J2EE），而在后端使用关系数据库 (RDB) 技术（如 Oracle 数据库）。这意味着您需要了解如何克服这两者之间的不匹配。幸运的是，这些技术相当简单，但的确需要时间和经验来学习。（我已经使用 Oracle Application Server TopLink 很多年了，因为它曾经也仍旧是可用的最高效的 O/R 可持续性层之一。TopLink 不是万能的 —您仍需要知道您在干什么 —但它几乎能够完成您曾经打算做的任何事情。）

因为对象和数据模式都以一种渐进的方式进行开发，所以您显然需要在将来发展您的映射 — 认识到这一点是很重要的。类似地，映射的困难可能促使您的对象或数据模式的改变（甚至可能两者同时改变），从而促使您更新模型。这正是要使用一个完善和集成的工具集（如 Oracle 开发套件）的又一个原因：您的工具需要密切地支持您需要做的工作。

重构

代码重构是对您的源代码的一些小的改进，它改进源代码的设计而不添加新的功能。示例代码重构包括重命名一个类、将一个操作从一个类转移到另一个类中、或者从一个操作中删除一个参数。这些都是简单的修改，但如果没有工具支持，它们可能需要相当可观的工作量。重构使您能够使设计保持高质量，并减少创建详细的设计模型的需要 — 如果您的编程人员很好地进行了重构，那么高质量的设计将很快产生。

JDeveloper 有一些基本的重构功能，但要得到完整的重构功能，请尝试使用 Agris Software AS 提供的 RefactorIT 扩展。RefactorIT 是一个领先的重构浏览器，允许您容易地重构代码的工具。例如，当您重命名一个操作时，您不仅必须在实施源代码中进行重命名，您还需要在调用该操作的每一个地方修改名称。重构浏览器自动地为您完成这些操作。

数据库重构是对数据库模式的一些小的改进，重构不改变数据库模式的功能或信息语义。数据库重构类似于代码重构，它使您能够在将来发展您的设计。不幸的是，数据库重构是如此之新，以至于您仍然需要用您现有的 DBA 技术和工具来修改数据库模式。（注意，当通过一个可持续性框架封装了对数据库的访问时，数据库重构变得容易了许多。）

测试驱动的开发 (TDD)

TDD 是这样一种方法：您编写一个新的测试，查看它是否失败，然后编写一小部分功能代码，以确保测试通过所需。然后您再反复地进行这个过程。这种方法的好处是您知道您的应用程序在任何时候都可以工作，而且这使得重构能够进行，因为知道您可以找出重构导致的任何破坏，您就可以安全地修改您的应用程序了。（对敏捷应用程序开发人员而言，TDD 是一种极其常见的方法。例如，JUnit 框架 (www.junit.org) 可以和 Oracle JDeveloper 10g 一起使用，而数据库测试框架（如 Dbunit (www.dbunit.org) 正变得越来越普遍。）

接下来的步骤

下载 Oracle JDeveloper

下载 OracleAS TopLink 10g

渐进式性能调整

因为现代系统使用好几种技术（包括对象技术以及 RDBMS），所以 DBA 必须准备好调整这两种技术和它们之间的交互。因为您在逐渐地交付可运转的软件 — 可能每月、每星期、甚至每天 — 所以您必须持续地进行性能调整。这意味着性能调整可能促使对象模式、数据模式或两者之间的映射的改变。此外，任意这些事物的改变都可能会有性能的影响，这反过来可能促使您的系统的另一个方面的反复改变。所有这些都是相互联系的。

一种偏激的选择

当问到他们对同事的看法时，多数开发人员和 DBA 都会说“我爱他们”或者“我恨他们” — 似乎很少有中间选择。在过去的十年里，软件开发已明显倾向于增量开发技巧，而在接下来的十年里，软件开发似乎将（甚至进一步）倾向于敏捷技巧。如果您想要成为一个人们能够愉快地与您合作的技术专家之一，那么您将需要采用敏捷技巧以及使您能够应用它们的新的工具。

对您而言，这些建议大多数可能听起来有些偏激。由于对象和数据社区之间的文化分歧，许多数据专业人士错过了对象革命 — 敏捷软件开发来源于此。更糟的是，就现代软件过程而论，数据社区中的许多“大思想家”都不幸落在后头了，坦白地讲，他们已经误导了数据社区相当长的一段时间了。

无论您是否同意这种观点，显然数据库管理员需要开始采用我在这里概述的渐进式技巧。否则，开发人员可能认为您是问题的一部分，而不是解决方案的一部分，并将想办法来忽略您。在我看来，这听起来可不是什么好事。


--------------------------------------------------------------------------------
Scott W. Ambler 是 Ronin International Inc. (www.ronin-intl.com) — 一个专门从事软件流程改进和体系结构咨询的服务公司 — 的高级顾问。Scott 编写了好几本书，包括《Agile Database Techniques:Effective Strategies for the Agile Software Developer》 (Wiley, 2003) 和即将出版的《The Object Primer 3rd Edition:Agile Model Driven Development (AMDD) with UML 2》（剑桥大学出版社）。