【IT168 技术文章】

    出于担心自己的技术会逐渐削弱、软件开发经验会日益缺乏，IBM 顶尖技术咨询小组考虑过一起放弃咨询而恢复开发组织，在开发组织中他们就可以恢复他们的编程兵工厂的勇气。他们决定拿起自己的长剑，正面与那些“龙”搏斗 —通过开发他们自己的 Web 应用。这些屠龙者不是用亚瑟神剑（Excalibur），而是用极端编程来设计、开发和测试集成了最新技术、使用了 IBM 工具和产品的应用。 Go-ForIt 系列的第 1 篇（即本文）为 DragonSlayers 的故事和使他们的咨询职业恢复活力的 Go-ForIt 应用搭建了舞台。

    本文讨论了我们的 Developer Relations Technical Consulting 小组负责的项目的几个方面。使用极端编程（eXtreme Programming，XP），我们用 IBM开发工具和技术为一个假想的公司 Go-ForIt.com 构建一个 Web 应用。我们讨论 Go-ForIt 项目的起因，包括负责这个项目的方式，以及项目目的和目标。我们还提供在手上的这个项目中构建的应用的高级概述。

    Go-ForIt 项目的主要目的是将我们的经验和我们所学到的知识归纳一下。在这个系列中我们将共同分享那些经验和获得的知识，本文是这个系列中的第一篇。后面的文章将详细说明为这个 Web 应用开发的组件、对体系结构和设计决定的讨论以及我们在开发过程中得到的教训。

    为何我们被称作 DragonSlayers（屠龙者）

    Developer Relations Technical Consulting 小组使用 IBM 软件工具和技术为 IBM 的商业伙伴提供体系结构、集成和咨询支持。我们的任务可概括为 4个 E：Excite（激励）、Evangelize（宣传）、Educate（教育）和 Enable（提供能力）。我们通过展示和演讲活动激励开发者对 IBM 提供的产品感兴趣。IBM 版的，开发的，基于标准的开发。我们提供关于 IBM 软件的正规教育。我通过电话和 Web 方式的咨询以及现场咨询使开发者能够使用 IBM 工具和技术。

    当小组或其中一个小组成员解决了一个极端困难的问题，或（通过给予培训和能力支持，使他们在开发中节省了时间和精力）使一个客户特别高兴时，我们作为一个小组会特别庆祝一番。我们开始把这种杰出的工作称为杀死了一条“龙”，不久我们就给自己起了 DragonSlayers（屠龙者）这个绰号。

    所有的 DragonSlayers都是程序员，我们在软件开发方面的数年经验在我们的工作中起到了很突出的作用。为使我们的商业伙伴取得成功，我们不能只告诉他们我们的产品怎么样，以及他们应该使用这些产品的原因，我们还必须一针见血地从技术角度详细告诉他们使用方法。只有程序员才能有效地将使用方法与另一个程序员联系起来。

    对我们来说，另一个关键因素是学习。如果我们要教会我们的商业伙伴，我们就必须是行家。软件技术正在快速发展，且发展速度之快可能是前所未有的，这是显然的且千真万确的。DragonSlayers 不断受到挑战，要跟上并维持他们在工具、技术以及出自实验室的标准方面的专门技术。这意味不仅仅要阅读技术手册，还有付出更多的努力，因为我们都知道阅读技术手册不会使人成为专家。您必须实际使用工具和技术。我们花费了相当多的时间和精力，亲自动手去了解每种新产品或新版本的细微差别和复杂性。

    冒险的业务

    随着越来越多的公司采用IBM的电子商务框架和连带的服务工具和技术，我们组也逐渐成长以满足那些公司的支持需求，我们面临着有没有能力持续提供我知道自己必须提供的高级咨询的冒险。

    第一个冒险是要使自己的技术和知识增长的足够快，能够一直领先于客户。我们在获取实际经验方面所花费的时间和精力与我们的客户天天使用这些产品所获得的经验无法相比。我们的客户过去开发大型、复杂的系统，推进了他们用于构建那些系统的 IBM 产品性能的提高。我们的主要任务是带领、指导我们的客户，但我们却要冒这个角色可能失败的冒险，因为我们的客户已经变得比我们对那些工具和技术更熟练。

    下一个冒险与我们员工的整体软件开发经验有关。我们知道，除技术上的技巧和能力外，软件开发也必需过程和方法。它包括分析和设计，团队合作，以及，也可能是最重要的一点，作为一个为紧迫的商业问题提供技术解决方案的功能系统的所有者而感到自豪。我们从事咨询业务的时间越长，我们的“真实”软件开发经验衰退得越厉害。

    这导致我们要面对最终的冒险 — 我们的组成员对最前面描述的两种冒险的响应。一些，大多数，甚至全部组成员最终都会离开这个组，而加入开发组织去获取他们感觉自己需要的技巧和经验，这种情况已变得明显起来。于是相当多的努力花费在了补充新成员和小组培训上，我们不想失去我们的任何有价值的人。

    解决方案：Go-ForIt.com

    一天晚上，当我们在当地一个酒吧讨论这些冒险时，我们想到了解决这个问题的方案。我们相信承担一个“真实的”开发项目会有助于我们解决和尽量减少面临的冒险。我们一致认为，我们的项目：

    #规模和涉及范围必须大到需动用 Technical Consulting 小组的所有成员

    #必须不是将来要投入生产的应用

    #但是，必须象实际问题的实际解决方案一样现实可信

    #必须有助于在其实现中使用大部分的面向电子商务产品和技术的 IBM 框架，还必须是我们的客户的问题和解决方案的典型代表

    #必须是无限度的，要不断改进和加强

    关于第二个标准有一些争议，但最终，我们知道我们的任务是支持 IBM 的商业伙伴，我们不希望造成我们的应用的用户和我们的实际客户之间的冲突。

    我们构思的项目是为一个假想的公司 Go-ForIt.com 开发一个 Web 站点。Go-ForIt.com 是一个个人差使服务。客户可在这个站点注册，并发送他们需要完成的差使；例如，收拾该洗的衣服，遛狗，排队等待许可证，等等。独立的承包者，比如知名的个人助理（ Personal Assistants，PA）也会在这个站点注册并对发送的差使投标。Go-ForIt 将把胜出的投标者与需要服务的客户配在一起，并按完成差使的报酬的一定百分比收取费用。

    我们知道，作为一个商业模型，Go-ForIt.com 将把自己归为 .com 类，这个滑稽得不得了的 .com 在去年都快破产了，但我们的重点是在技术方面，我们相信这个应用会符合我们的标准。

    我们的主要目标是获取有现实意义的软件经验，但我们意识到 Go-ForIt.com 还能够帮助我们达到小组的另外两个重要的目标。第一，我们会从这个项目中获得大多数或全部的课程资料，第二，我们可以经常抽取提出的问题、提示和技巧、技术论文和其它的技术内容与软件开发社区共享。

    谁的错都不是

    为实现我们的思想，我们制定了一套原则来表明我们的项目的基调和指导思想，如下所示：

    #关于这项目的每件事情都是开诚公布的、理由充分的、经过深思熟虑的，即使这些原则也是如此。组中的每个成员都有义务对自己不理解的或认为不正确的决定提出疑问。

    #我们不要忘记我们的主要任务是支持我们的客户。这个任务优先于其它任何事情，包括这个项目。毕竟，我们从事这个项目也是为了获得技巧和经验，以便能够更好地支持我们的客户。

    #但是，我们不会将这个项目当作业余的或随意的活动来对待。我们将把这个项目的各种分配、进度表、截止期限等等当作我们想要实际部署的真实项目一样认真对待。

    #关于这个项目的一切都作为实际项目来建立和管理，包括配置管理、编码标准、进度表、截止期限、文档编制、集成测试、验收测试、紧急错误修复、性能测试和调优，等等，要一直牢记原则 #2。

    #我们将使用极端编程（XP）作为开发过程。XP 是一种严格按照要求进行的软件开发方法，它接受更改（认为这是不可避免的），并相应地制定计划。我们选择 XP不是因为它新而且简洁，而是因为它能解决我们在这个项目中面临的困难。它被设计用于模糊而迅速地更改要求，提倡较短的开发周期以便最大程度地学习，并要求持续测试和重编代码以确保其正确性。我们的客户正在评估XP；有些客户可能已经在使用XP。XP 是软件开发上的重大改革，我们应该具有 XP方面的经验，以便能够聪明地与我们的客户进行探讨。

    #这个项目不必根据委员会意见或经一致同意才运行。组中的一个人将担任这个项目的经理，从而负责这个项目的管理决定。组中的一个成员将担任这个项目的体系架构设计师，并负责所有的技术决定。组中的一个成员将充当客户，负责所有的业务决定。整个组将作为一个战略家，负责这个项目中将包括 IBM的什么产品和技术的所有决定。

    这条原则和原则 #1 并不冲突。一切都是可以自由挑战、自由提问和自由辩论的。但有时候，必须做出决定才能前进。委员会是出了名的喜欢通过冗长的讨论来拖延和推迟决定。我们没有时间那样做。但是，我们计划过一段时间在小组成员之间轮换一下角色，这样所有的成员都能得到软件开发不同方面的经验。

    #没有任何小组成员将变成这个项目的任何部分的专家或这个项目所使用的任何产品和技术方面的专家。任何小组成员都不得以缺乏经验为借口，拒绝从事项目的任何部分，或这个项目所使用的产品和技术。没有任何人被指定为只负责“思考”。每个人都要编写代码。这里没有 HTML 专家、Java 专家、JSP专家等等，我们争取让所有的成员都得到尽可能广泛的经验。这个项目归集体所有，但是每个成员都应该把自己当做整个项目的主人翁。

    #无论何时出现了问题，谁的错都不是。这个原则是 XP哲学的一部分（适合我们的情况）。出现问题时（问题是不可避免的），自然的反应就是指责某个人。但指责是没什么用的。我们需要做的是修正问题，至于是谁的错误真的并不重要。所以，无论何时出现了问题，我们都不要抱怨任何人，要赶快着手修正问题。

    我们已经制定出了这些原则，并把这些思想形成了建议，呈交给喜欢这些思想并很快批准这些建议的管理部门。然后我们将这些建议向整个组公布，并召开了一次会议回答所有的问题，说明大家关心的每个问题。接着，对涉及的所有成员进行了几次 XP 培训，并于 2001 年 1 月开始着手这个项目。

    Go-ForIt.com 应用

    这部分描述了 Go-ForIt.com 应用，但仍在相当高的级别上。后面的文章将深入到项目开发的细节问题。

    为开始构建 Go-ForIt 应用，并使 XP 模型尽可能真实，我们指定 4 个小组成员作为客户。他们提出一套用户情景（User Storie）。用户情景是从客户角度出发的要求，包含极少或不包含实现细节问题。他们代表客户将如何使用这个系统的观点。为保持事情易于管理并避免个人情景太长、太复杂（我们的客户小组中的某些成员一向以小题大作出名），我们要求每个情景写在一张 3x5 开的索引卡片上。情景一旦被定义，我们就开始把每个情景分解成一组任务，然后实现这些任务。（您可以看到情景的完整列表以及它们的当前实现状态。）

    设计指导思想

    我们用从零开始实现用户情景。但是，我们的确有一套大家都遵守的通用设计原则。这些原则是在用户对商家（User-To-Business）模式的指导下制定出来的，这种模式是IBM电子商务模式的一部分，有一组可重用的资源，有助于加快电子商务应用的开发速度。

    这些原则如下所示：

    #我们使用 Java 编程语言（组中有人建议使用 Perl，结果不得不在重重保卫下才安全走出房间）。

    #用户界面（UI）是基于 Web 的。

    #UI 的静态部分是用 HTML 实现的。

    #UI 的动态部分实现为 JSP 页面。

    #持久数据（例如，用户信息、差使请求信息）表现为容器管理持久性（Container Managed Persistence）实体 bean。

    #实体 bean之间的关系（例如，指出某个差使请求是某个特定客户发出的）是用关联处理的

    #用户的所有行为都是由 servlet 处理的，servlet 先调用相应会话 bean上的适当方法，然后再调用适当的 JSP 页面向用户返回行为的结果。

    #通过开发一个命令 bean 简化了到会话 bean 的 Servlet 接口，命令 bean是一个简单的 JavaBeans 组件，带有 setXXX()方法（用来提供用户供应的数据），一个不带参数的 execute() 方法（用来执行任务）和 getXXX()方法（用来提供结果（如果有的话））。命令 bean 抛出异常来指明错误情况。

    #会影响持久数据的任务（例如，添加用户、更新用户信息）由 EJB 会话 bean上的方法来表示。

    #简单的用户输入验证（例如，验证一个电话号码格式是否正确，或验证是不是已经输入了所有必需的输入）用客户端的 JavaScript 来完成。

    #这个应用可配置在任何支持 WebSphere 应用服务器的硬件平台上。

    开发工具

    我们使用下列工具开发 Go-ForIt：

    #WebSphere Studio 3.5 高级版用来开发 HTML 页面、JavaScript 和JSP。

    #VisualAge for Java 3.5 企业版用来开发所有的服务器端代码：EJB、servlet和与它们相关的助手类。实体 EJB 之间的关联使用 VisualAge for Java中的持久性构建工具（Persistence Builder Tool）完成。

    #VisualAge for Java 3.5 Team Server管理开发小组中的成员共用的一个资源库。

    关于在 XP 环境下使用 VisualAge for Java 的更多信息，请参阅参考资料。

    测试

    XP的基本要求之一是每个项目应该有一套综合的自动测试，测试可能出错（带有自然反应的可能异常）的任何东西。当我们发现错误时，我们编写测试案例来找到错误并在修正此错误之前将其添加到套件中。关于在 XP 中进行测试的更多信息，请参阅 eXtremeProgramming: Deceptively simple innovation。

    我们使用 JUnit 测试框架（请参阅参考资料）为我们的 EJB 组件、命令 bean 和其它所有相关的助手类编写合适的测试案例。

    结论

    Go-ForIt.com 项目已经开始实现我们的目标了 —保持技能和共享技术信息。为保持和增加咨询小组的技能深度，我们正在关注 Go-ForIt项目的相关发展领域（即我们的商业伙伴的发展领域）。有了这些相关技能，我们就能够完成我们这个组织的任务的一半— 教育（educate）我们的客户，提高他们的能力（enable）。但是，我们没有忘记我们的 4 个 E 的另一半 —

    激励（excite）我们的客户并向他们宣传（evangelize）。所以，当 IBM 向我们的商业伙伴介绍并推荐新技术时，Go-ForIt 项目也会反映这些新技术。Go-ForIt 测试技术的有效性，并使我们的顾问能够说出它的可靠之处。

    我们正在发掘 Go-ForIt 项目中的技术信息，用来共享：“使用指南”文章、样本代码、相关主题的课程、常见问题的解答以及优秀教材（Mentored Workshop）的素材。朝着这些目标，目前为止Go-ForIt已经是相当成功了。然而，通过咨询小组坚定不懈的努力，Go-ForIt 已经越来越引人注目，这里特写的是第二次修订版，其中学到的教训可与IBM商业伙伴和个人开发者共享，并被他们使用。

    在后面的几周或几个月中，我们将把从 Go-ForIt 得到的经验归档，并与您共享。我们将讨论我们是如何如何开发各种组件的，我们做出的设计决定以及在此过程中遇到的陷阱和取得的成功。让我们休息一下，回味一下这个过程。我们已经从这次编码冒险中学到，并将继续学习许多东西，我们期望听取来自开发者社区的意见：我们所做的哪些是错的，哪些是对的，以及您自己在电子商务应用开发领域的经验或 XP 方面的经验。

    参考资料

    参与本文的讨论论坛。
    阅读 Go-ForIt 系列的第 2 篇文章，了解为什么 DragonSlayers选择用极端编程来与开发他们的 Web 应用过程中的困难作斗争。
    研究 IBM 电子商务模式，它预先建立了用于创建和实现大型集成系统的设计。
    访问 JUnit 站点，获取关于 JUnit 开放源代码回归测试（regression
    testing）框架的信息，该框架使得在 Java 中进行单元测试成为可能。
    通过本文学习在 IBM VisualAge for Java 中进行极端编程，这篇文章出自 IBMDeveloperToolbox。 重温 Go-ForIt 应用的用户情景（客户要求）。
    解决方案 2001 提供了下列相关的会议：
    Roadmap to Architecting e-business with IBM WebSphere Programming Model Best Practices for HttpServlets and JavaServer Pages
    WebSphere Programming Model Best Practices for Enterprise JavaBeans
    Hands-on: VisualAge for Java Version 3.5.3