技术开发 频道

编码冒险开始

    谁的错都不是

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

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

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

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

    #关于这个项目的一切都作为实际项目来建立和管理,包括配置管理、编码标准、进度表、截止期限、文档编制、集成测试、验收测试、紧急错误修复、性能测试和调优,等等,要一直牢记原则 #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 应用服务器的硬件平台上。

0
相关文章