Cavingdeep的.NET专栏

XP作为一种还算年轻的软件研发的方法论目前应该可以说开始普及了。作为一个软件研发人员，我非常赞同XP理念，XP的理念中充满了使项目成功的关键思想，而这些思想不仅仅是技术上的，而是很大一部分是管理与沟通方面的。XP集成了许多最佳实践，而这些串连后的最佳实践使整个项目又变的有趣起来，这其中也包括了XP开发人员特有的积极向上的态度与责任心。这里我想向大家描述一下我个人的XP实践感受……

下面我分别写一下我对XP中其中12种最佳实践的感受：

1. 现场客户(On-Site Customer)。客户的需求不是一成不变的，往往在需求收集阶段事情总是很抽象，就连客户自己都不知道他们具体要什么，他们只是提供一个轮廓，要我们双方共同去构造理想中的产品。但是我们，包括客户都不可能预测说我们现在定下来的需求就是真正的一成不变的需求，总是有千万个理由会促使需求的变动，也就是说需求的变动是必不可免的，它不是单纯的可以人为控制的。那现在的问题是，但需求变动时，我们有能力迎接（适应）它吗？现在XP提出了几种最佳实践来迎接需求的变动，而其中一种既是On-Site Customer，通过客户在整个项目中的不断参与我们可以保证我们所作的一切都真正是客户想要的，而我们不会浪费时间与精力在不需要的功能上。这是按时交货，交好货的一种关键做法。注意这个最佳实践要求的并不是客户每天8小时的参与项目，而是但我们需要客户解答某些需求疑问时，客户能及时的提出意见，给出反馈！
2. 小发行版(Small releases)。上面提到了需要客户能及时给出反馈，那么及时得到反馈的一种好的做法就是提供给客户软件的预览版，毕竟没有实物客户很难提出他们对我们正在做的项目的看法。XP要求小发行版正是这个用意，通过快速的小的迭代开发得到很多的小版本，然后将这些小版本拿给用户体验，收集反馈，再根据用户的反馈继续下一个小版本的迭代开发，这是一个良性循环，保证了项目不走歪路，保证了客户对我们正在做什么没有偏见，同时也保障了项目的质量，因为直接参与测试的同时也有我们的客户。
3. 简单的设计(Simple Design)。上面讲的是从需求的角度出发的，现在让我们来看看开发流程方面。我们都知道设计是好的，而事物总是保持越简单越好，那么为什么不选择简单的设计呢？通过简单的设计我们可以快速的理解与开发。但是但靠简单的设计往往不是很有作用，很快我们就发现以往的设计已经不再有弹性，很快就不能满足我们的需要了。这里就是体现XP精华概念的时候了，XP中有极限一词，也就是说不管是做什么，都要做到极限。简单的设计也不例外，同样也要不断的迭代，通过在简单的设计上重构出另一种简单的设计来不断改变设计与设计质量，会让你在不知不觉间作出与超级设计大师一样优质的设计。（当然，如果你真的很糟糕，那么即使XP再好我想也帮不了你了）
4. 规划策略(Planning Game)。既然简单的设计有助于快速的进展那么不断的规划也一定会帮助到项目的方方面面。很难说架构师做好的架构就一定不会在后期改变，既然需求都很有可能有大改变，那么架构与整体项目规划也不是一成不变的。这是XP的核心，XP告诉你如何迎接变化，如何在快速变化的今天作出最优质的产品，真正满足客户的需求。
5. 系统隐喻(System Metaphor)。说实话，我也是刚刚开始真正了解XP，所以对这个实践还不太了解，所以这里就不谈了，免得败坏XP的名声！^_^
6. 重构(Refactoring)。我想很少有人在这个年代没有听到过重构吧？上面所讲的很多方面都是基于这个思想的。既然设计是好的，那么我们能不能快速的、小步的迭代设计呢？能不能通过不断的改善已有的代码来使它们更健壮呢？目前的项目大多数都会在维护一段时间后变的僵硬，代码越来越难以维护，有时不得不写一些自己都认为很难看的代码来维护新增或修改的功能，而正是这样的动作导致了下一次维护时的困难，使代码陷于了恶性循环，使的项目的维护成本越来越高，最后不得不放弃维护而重新开发。XP提出了迭代的重构方案，它使我们每一次都先重构再在重构好的代码的基础上再做修改，这使得我们每次都不用花太多的精力去完成对代码的维护而又与此同时提高了代码的简易度、健壮度。
7. 结对编程(Pair?Programming)。既然对设计、对代码的评审是好的，那么为什么不随时评审呢？通过评审，我们可以用多个人的脑袋想问题，寻找解决方案，无疑这要比只用一个脑袋要好的多，毕竟人多力量大嘛，曾经也有教育家做过试验，证明了在群组讨论学习的环境下学生学到的知识更深刻，理解的更透彻，思想也更活跃。软件开发又何尝不是如此呢？我不完全赞成“结对”，但是我赞成有问题就问，不管什么样的问题，不管什么样的同事，只要你有疑问，那么你就可以向大家提出来，看看每个人的想法，这会使你最终得到一个当前最好的解决方案。
8. 集体所有权(Collective Ownership)。在上个实践中其实已经提到了这个集体所有权的概念，既然你有问题就可以问，别人又都参与你给你他们认为的可能性答案，那么是不是反过来但别人有问题的时候你也要主动参与提出自己的看法呢？这种把多个大脑运作在一起的模式就是XP中集体所有权的概念了，在这里没有个人的殊荣，只有团体与团体的共同目标。注意这里就是XP的特点了，XP是以人为本，XP坚信人与人之间的作用要比单纯的依靠技术要更重要的多。毕竟只有最后依靠到人心上，项目才可能获得最后的成功。而作为一名XP开发人员也意味着你的个人休养与风格。
9. 编码规范(Code Standards)。代码在XP中被看作一项非常重要的在开发人员之间沟通的工具。毕竟软件反映了开发者的心智，开发人员的思想变为一行行代码被写在程序中，这是一门艺术。但艺术也要有人去欣赏，如果每个人都看不懂其他人的艺术，那么怎么进行沟通呢？集体所有权让我们每个人都可以去改进其他人的代码，那么如果没有统一的编码规范将不是一件容易的事了。
10. 一周40小时(40-Hour Week)。XP不主张加班加点，这只能是当有某些环节出问题的前兆。XP在每次快速的迭代中都很明确下一次迭代要做什么，XP有很高的可控性。
11. 测试(Testing)。测试是XP的核心部分，是XP重要的环节，也正是处于这种原因，我将两种测试放在了最后面介绍，不是因为它们不重要，而相反是因为它们太重要了！测试其根本目的是为了保证质量，告诉我们所作的一切没有白做，它的确可行。XP中的自动化测试（常指简单有效的单元测试）是非常关键的，它有多重目的。其中一个很重要的目的就是给予我们开发人员信心，试想每次系统变动后运行自动化测试时看到一排路灯亮着是那么畅快的一件事啊！XP主张先测试后编码，每次的测试用例都能够反映出最确切的需求，测试亦是设计的一部分。其中的奥妙真的是只有真正用过才能体会得到。
12. 持续集成(Continuous Integration)。这是另一种保证质量的测试手段，通过反复快速的集成我们可以及早发现软件中的隐患，同时持续集成也可以提供给我们多个小版本(Small Releases)以便客户的反馈。这个概念比较像微软提出的每日编译，只是XP并没有规定必须每日执行一次，XP反而主张每几个小时甚至每几分钟集成一次，总之就是当有较大变动时就及时集成给出反馈，这一点也能够充分的体现出XP极限编程中的极限来！

好了，以上是我个人在对XP有了一定充分的了解后所得出的结论，供给大家参考，我个人及其欣赏XP勇于创新的概念以及其在项目中的实际运用。虽然Kent Beck不主张将XP中的最佳实践剪裁掉使用（他主张将XP就像其概念一样统统发挥到极限，每一样都用的淋漓尽致），但是我个人还是同意每个组织根据其特性考虑去掉或消弱某部分实践来真正将XP运用起来，而不是只停留在大家都评论却没人敢去做的现象中。

打印 | 张贴于 2005-03-10 14:47:00 | Tag:Methodologies