极端编程：虚假的简单革新

　　极端编程：虚假的简单革新

　　【作者】:

　　Willy Farrell （willyf@us.ibm.com），电子商务体系架构设计师，IBM

　　Mary-Rose Fisher （mrfisher@us.ibm.com），电子商务体系架构设计师，IBM

　　2001 年 6 月

　　在本文中 Willy Farrell 和 Mary-Rose Fisher 讨论了开发者引入软件项目的四点价值：沟通、简单、反馈和勇气。极端编程是一套应用这些有价值的东西来创造一个环境的惯例，在这个环境中，您可以快速而正确地开发商业应用。同时还讨论了极端编程的 12 个基本惯例。

　　“听取意见、测试、编码、设计。这就是开发软件要做的全部工作。任何告诉您不是这样的人都是想推销什么东西。”— Kent Beck，极端编程的作者。

　　沟通，或更准确地说，缺乏沟通，是几乎所有软件问题的根源。客户没与开发者沟通他的要求，或开发者没与客户沟通提供一个功能的困难之处。如果涉及的各方直接，及时地互相沟通，就可以消除大多数问题。我们不能忽视或惩罚任何诚实的沟通。

　　简单。有什么最简单的事情可能会起作用？我们的注意力太多放在了软件的最复杂难解的功能上，而这些功能我们很少用到或者只是曾经用过。今天做简单的工作，明天花点代价修改它要比今天做可能永远用不到的复杂工作好的多。这也和我们的沟通价值紧密联系在一起，因为系统越简单，需要的沟通越少。

　　反馈告诉我们工作做得怎么样，以及以后要如何做。我们需要对正在运行的系统的反馈，以便了解它是否满足了客户的要求。我们需要通过反馈来了解系统将需要哪些最有价值的改进、加强和附加。我们还需要通过反馈来了解，我们什么时候能够交付某个特定的功能。如果不知道以前的速度又如何确定将来的速度？

　　我们还把勇气带进了软件开发中。我们有没有勇气尝试新的、不同的东西来大幅减少项目时间？我们有没有足够的勇气在即使面对巨额预算和截止期限压力时仍能坚持做正确的事情？

　　你有勇气吗？是否已厌倦了过度复杂且缺少真正有创意的项目？有没有做好准备去谈判，而不是让别人指定预算和时间限制？想真正了解用户的需要和愿望吗？那么来吧 — 开始使用极端编程吧！

　　极端编程说明

　　极端编程（XP）是一套用于软件开发的惯例，它应用上述的几点价值来创建一个环境，该环境有助于快速、准确地开发商业应用。如果您编过一段时间程序，可能在看到下面的惯例时会想：“这些也不新鲜；我以前已经做过其中一些了。”您是对的。

　　XP的革新只是把所有的惯例放在一起，以便它们互相支持。一些惯例的优势会弥补其它惯例的缺点。

　　您可能会突然想起非正式的 XP 看起来应该是什么样的。但不要被愚弄了 — 虽然它是非正式的，但同样要求许多纪律。您不得不遵守这些 XP 惯例，这里指的是所有的 XP 惯例，要不您就不是在进行极端编程。

　　XP 的 12 条惯例

　　#规划游戏

　　#小型发行版

　　#共享智力模型的隐喻

　　#测试

　　#正确的设计

　　#重组

　　#成对编程

　　#集体所有权

　　#连续的集成

　　#每周 40 小时工作制

　　#现场客户

　　#编码练习

　　基本原则

　　在讨论这些惯例之前，这里还有一些基于上面的四点价值的 XP 基本原则。

　　#快速反馈

　　行动和对该行动的反馈之间的时间是至关重要的。您需要马上知道事情是好是坏。

　　#假设简单

　　它可以节约时间。对待每一个问题都好象可以绝对非常简单地解决。几乎任何时候，都可以这样简单地解决。您节约了要在实际需要复杂解决方案的问题上花费的时间。

　　#递增更改

　　大的更改是不起什么作用的。即使在最小的商业应用中也有太多的关系和互相依赖，使我们想象得到对体系结构或代码的大规模更改肯定会产生问题。但随着时间的推移，进行一系列的使得所开发的商业应用有所不同的最小型更改，最终会形成大规模的更改。

　　#信奉更改和高质量工作

　　有人说，这个世界上没有一成不变的东西。我们必须接受，甚至信奉更改。但不是要预计可能发生的每个可能的改变，如果在解决我们的大多数紧迫的问题时能够制定出保留选择余地的策略，这样会有效的多。

　　至于高质量工作，有两种选择：优秀和极端优秀。不要做比这差的工作。与我们同事的所有优秀程序员都有干出优秀的、高质量的工作的信仰。

　　听取意见、测试、编码、设计 — 按照这个顺序

　　现在让我们围绕已经讨论过的价值和原则构建我们的开发活动。我们要执行的最重要的活动有：

　　#听取意见

　　#测试

　　#编码和设计

　　按照这个精确的步骤执行。为什么要按照这样的步骤？在后面我们会稍加说明。

　　只是简单地互相听一下意见是不起什么作用的。我们必须真正用心去听，只交流那些确实需要交流的内容，而不是我们惯常谈论的那些与主题无关的无价值的东西。

　　制定一些规则以确保鼓励交流真正值得交流的东西，而阻止交流无关的内容。交流无关的内容只是浪费时间。

　　使所有的测试自动化。如果无法测量的话，自动测试不会存在。自动测试会增强我们对系统的信心，并使我们自信有能力进行提高质量的更改。我们需要两种类型的测试以适应两种用户：单元测试（针对程序员）和验收（或功能）测试（针对客户）。

　　开发工作绝对无法缺少的一种人工制品是我们写出的真实的、全能的代码。我们的代码表达了目的、算法和结构。代码要写得清楚而明了。

　　如果代码最终是可交付使用的，那么设计就至关重要。我们必须创建一个结构将系统中的逻辑组织起来。只是因为一个部分中的逻辑要求修改时不能必然意味着另一个部分中的逻辑也跟着要求修改。将逻辑放在数据（逻辑在该数据上操作）的旁边允许只在一处更改的系统扩展。设计必须要有上下文，在上下文中可创建好的设计，修改不好的设计，而且与项目有关的每个人都能理解标签。

　　现在，感觉这个奇怪的顺序怎么样？在 XP 中，开发是象这样进行的：我们听取需要做什么。然后，编写测试，如果通过了，则证明我们交付了需要做的东西。下一步，我们编写将通过那些测试的代码。最后，我们调整代码的设计使其更简单、更有效，同时仍能够通过测试。

 如果您对本文有任何疑问或者建议，请到讨论区发表您的意见: >> 论坛入口 <<

上一页12 3 下一页

上一篇：J2ME 简介   下一篇：标准建模语言UML及其支持环境(一)

【文章评论】 【收藏本文】 【推荐好友】 【打印本文】 【我要投稿】 【论坛讨论】