对极限编程四个核心的理解

极限编程的核心有四个，交流、简单、反馈和勇气，这四个原则大家在平时做项目的过程中一定也注意到了。但是两位大师 Kent Beck 和 Martin Fowler 能够把这四点归结在一起，使他们能够共同组成极限编程这架四轮马车，却是一个不小的创造的。

下面仅就自己的学习和简单的实践过程中遇到的问题来谈谈自己对这四个核心的一些理解。

<!-- [if !supportLists]-->一、 交流 <!-- [endif]-->

<!-- [if !supportLists]-->1) <!-- [endif]-->开发人员与客户的交流

这一点与传统的软件工程中有些类似，在平时开发软件的过程中也非常注重与客户的交流，特别是在需求分析、概要设计以及验收测试的时候，开发人员与客户有效的交流是必不可少的，那将直接影响到一个项目是否能够符合客户的要求。

然而，在极限编程中客户所处的开发阶段有些不同，传统的项目开发过程中，客户只在最初的时候和最后的时候需要和开发人员在一起，他们的责任也就是在于业务功能上的帮助，但是这样就不可避免的导致了这样的一个状况：在项目最初的时候客户提出了错误的或者不准确的需求，然后项目组开始开发，客户很长一段时间不介入项目，而在项目验收的时候发现有些地方有错误或者需要修改，此时项目组不得不付出很多的时间和精力来适应客户的需求。这是时间和资金上很大的浪费。在极限编程中，需要一个非常精通业务的现场客户，他们不仅随时提供业务上的信息，而且要编写业务验收测试的测试代码，这样就可以在很大的程度上保证项目的方向不会错误。

极限编程的过程是“瞄准－》射击－》调整－》调整”的过程，并不强求在项目开始的时候就准确把握项目的方向，由于有现场客户的存在，项目的方向是不断的调整中的，这样就可以极大程度上避免项目走弯路。

<!-- [if !supportLists]-->2) <!-- [endif]-->开发人员之间的交流

当前在招聘开发人员以及其他一切的工作人员的时候，我们都会强调团队精神，但是在实际的工作过程中，我们除了在出现问题，而且自己解决出现很大困难的时候才会去请教别人（我以前是这样的，可能每个人都会不同），再就是大家能够一起聚在一起闲聊、吃饭、唱歌等等开发过程以外的活动。以上的这些的确可以使团队之中产生一定的凝聚力，可以让大家和睦相处，但是离真正意义上的团队还有一定的差距。

我们所受到的教育一直培养的是一种独立解决问题的能力，所以，再遇到问题的时候我们想到的大多是自己来就解决，而不是和其他人一起来完成。

极限编程的实践中有一个非常重要的原则就是结对编程，这个原则看起来似乎有些奇怪。因为我们第一个想到的问题就是让两个人来同时做一件事情，那么不就是浪费了一个人的生产力了吗？但实际上并非如此，这里所谓的结对编程并非是一个人在编程，另一个在看着，另外一个人也同样起着非常重要的作用，他的大脑也在不停地运转，他需要帮助编码的人找到低级的失误，防止其编码出现方向性的错误，特别是在出现一个正在编码的人不擅长解决的问题的时候，他会直接拿过键盘，与其交换角色，直接来进行编码。

这样做的好处也许只有在实践了之后才能够体会到，它不仅可以避免一些错误的发生，而且可以通过直接的讨论来解决一些容易产生歧义的问题。而且两个人的思路碰撞出来的火花，能够更加快速的解决问题。而且，在交流的过程中，大家的水平也会有很快的提高。结对编程的过程也是一起学习的过程。（只可惜我这里只有一个人，没有办法长期实践，但只要有机会我就会努力的）

<!-- [if !supportLists]-->3) <!-- [endif]-->开发人员与管理人员的交流

在一个项目组里面，管理人员和开发人员之间的关系是影响项目的一个非常重要的因素，如果处理不好的化，可能会直接导致一个项目的失败。而管理人员所具备的素质更是要求很高的。如果是一个从技术人员转型的管理者，那么他的管理能力需要很大的提高，否则就会因为管理能力的缺乏而导致项目的混乱。而对于一个单纯的具备管理技能的人来说，如何能够得到技术人员的佩服是十分重要的，否则根本就无法使开发人员听从管理，那么他的位置也就岌岌可危了。

而且，如果开发人员能够和管理人员进行好的交流，那么他们的工作环境就会得到很大的改善，并不一定要非常豪华的房间和高级的家具，只需要一个可以非常舒服工作的环境，就可以让一个团队的战斗力得到很大的提升。而且，对于一个项目的计划和预算，如果开发人员能够提出自己的想法，就会避免最后争取到了项目却最终得不到利润的情况的出现。

管理人员也应该主动的听取开发人员的意见，很多的开发人员都是一些比较内向的人，如果不向他们询问，他们只会将自己心中的不满埋在心中，最后的结果是突然的爆发，然后辞职离去，造成重大的损失。

<!-- [if !supportLists]-->二、 简单 <!-- [endif]-->

<!-- [if !supportLists]-->1) <!-- [endif]-->设计的简单

在极限编程的过程中，提倡一种简单设计的实践。这样做的原因是由于过多的设计文档会使我们浪费太多的时间在上面，而且设计文档没有不修改的，可能在项目结束的时候，我们会发现当初的设计文档早已经使面目全非了。

所以，我们在最初的设计工作中要做的是明确我们要实现的最重要的功能，然后设计出总体的框架和核心的技术，这些文档从头到尾不会超过十页纸，那样即使有了一些改变，我们也不需要花费太多的时间来进行修改了。特别是在有了修改之后，我们不需要费很大的力气去让代码和文档完全一致了。

但是，简单的设计并不意味着这些设计是可有可无的，相反，那简单的几页纸更加重要，因为一个项目的核心内容都在上面，所以在编写的过程中一定要慎重。

<!-- [if !supportLists]-->2) <!-- [endif]-->编码的简单

编码的简单表现在迭代的过程中，在极限编程的过程，并非要一下子实现所有需要的功能，也不需要一下子就完成以后不再改变，相反，变化在极限编程中是被提倡的。我们可以先简单的实现一点功能，然后添加详细的内容，再后对程序进行重构，最终的代码将是非常简单的，因为依照重构的原则进行修改了之后，所有的类和函数、过程都是非常简短而非冗长的，每一个模块完成的功能是非常明确的。

但是，不要把简单和随意等同起来。尽管我们要实现简单的编码，依然要有编码的标准，使得所有的人都能够很容易的看懂我们编写的程序。其它象属性要使用名词来定义，过程要使用动词来开头的标准也是非常有用的，我们应该遵循。

<!-- [if !supportLists]-->3) <!-- [endif]-->注释的简单

在某些项目中，注释要求是非常严格的，甚至于规定在一个程序中注释量必须要达到一个百分比。这个初一看起来很有道理，因为注释能够让我们更好的理解程序的功能，但是细想一下，却完全不是那么一回事。

曾经有人说过“一般的程序员能够编写出计算机能看懂的程序，而一个真正的高手能够编写出普通人也能够看懂的程序”。的确是那样，与其让注释来解释程序，不如在给变量和过程、函数起名的时候用大家都能够理解的，那样即使没有太多的注释，另外的一个程序员想要读懂你写的程序也不是一件非常困难的事情了。

所以，在编写代码的过程中应该尽可能的使用代码本身来说明问题，而非借助注释的帮助，我们要编写的是代码，如果里面带有太多的无关轻重的代码，一方面会浪费我们的时间，还可能引起歧义；另一方面向微软的 Windows 源代码里面充满的发牢骚的注释就更不应该了。那些注释只是会给阅读代码的人带来分散注意力的效果了。

<!-- [if !supportLists]-->4) <!-- [endif]-->测试的简单

通常我们的项目如果是按照瀑布式开发的化，测试会全部放在编码完成之后，其中包括单体测试，集成测试，功能测试以及验收测试等等，而且大多数的测试是通过手工来完成的。所以依据经验来说，如果编码使用了 20 ％的时间，测试至少要用掉 40 ％以上的时间。而且在测试的过程中，还有好多问题需要修改，这也是导致测试耗费了大量时间的原因。

而在极限编程中，测试是通过编写测试代码来自动化完成的。特别是在一些面向对象的编程环境中，我们可以使用 xUnit 工具来快速、有效的进行单体测试。而且编写这些单体测试代码甚至可以是在正式编码之前。每一次修改了程序之后，都要运行测试代码来看程序是否有问题。而且对于程序的集成，极限编程提倡的是持续集成，也就是不断的将编写好的通过了单体测试的代码模块集成到编写完毕的系统中，在那里可以直接进行 Test Suit 的集成测试，从而保证代码不会影响到整个系统。

我们可以看到，极限编程中的编码和测试都是一小步一小步的进行的，这样就方便我们及时的发现并修改出现的错误。而自动化测试工具保证了我们的工作的效率，使我们避免了过多重复的工作。

<!-- [endif]-->

三、 反馈

<!-- [if !supportLists]-->1) <!-- [endif]-->客户对软件的反馈

在极限编程中一个很重要的实践是有现场客户，从此也可以看出来对客户反馈的重视。有了现场客户，就能够随时对软件做出反馈，能够保证在“瞄准”的过程中不断调整，保证软件前进的方向。而且，现场客户还可以对开发人员在开发过程中遇到的问题随时做出反馈，那样开发人员就可以避免由于自己的主观猜测而出现的错误了。而这正是在传统的软件工程的编码阶段程序员最容易犯的错误，因为在那个阶段，已经没有客户的参与了，编码人员只是根据详细设计来编写代码，对业务的不了解往往会造成编码和单体测试都非常困难，甚至于出现严重的错误，一直到最后验收测试的时候才能够被发现，而此时修改的代价是非常大的。由此我们可以看到由于现场客户的存在，把这些可能出现的错误消灭在了萌芽状态，很多时间、精力以及资金都节省下来了。

但是并非说我们可以从客户的公司中随便找一个人来做现场客户就可以了，现场客户的选择也应该是一个可以直接影响到项目的成败的因素。一个好的现场客户不仅可以准确的把握软件的方向，回答业务问题，而且可以编写验收测试，保证软件中的业务数据没有错误。这样就要求他不仅是一个管理人员，而且计算机的水平也要有一定的高度。这可能在国外并不难找到，但是在国内可能会有很大的困难的。

如果一旦没有现场客户，那么我们必须要有相对应的方案来应对。我想一种方式可以是这样的：保证有一个系统分析员级别的人，他可以少量的参与编码的工作，因为结对编程的过程中他会给大家很多的帮助，另外他还有一个更加重要的任务，就是负责与客户之间的交流，及时的将经过短期迭代的小版本的程序交给客户，并听取他们的反馈意见，也就是要他起到开发人员和客户之间的一个桥梁的作用。

<!-- [if !supportLists]-->2) <!-- [endif]-->测试代码对功能代码的反馈

在极限编程中提倡的是“编码未动，测试先行”，也就是说在编写功能代码之前就先要编写测试代码，测试代码可以用来保证我们的功能代码的运行是否正确。一般来说，我们都是使用 xUnit 作为开发测试代码的工具的。

有了测试代码之后，功能代码的编写更加像是一个解决问题的过程，什么样的问题呢？也就是让 xUnit 的那个状态条变绿的问题。我们需要不断的调整我们的功能代码，让状态条不断的从红色变成绿色，看着那种环保的颜色，我们的心情也会变得好起来。

这个方法在程序需要不断变化的时候尤其有用，因为我们在一般的情况下，如果修改了功能代码，那么以前所作的测试工作都需要重新来一遍，那样既浪费时间，又容易出错。有了自动化的测试代码，我们只需要运行一下 Test Case ，看它给我们的反馈是什么样的就可以了。如果 xUnit 代码给我们的信息是没有错误，我们大可以放心的继续我们的工作了。

但是，并非是说有了 xUnit 工具就万事大吉了，我们必须要很好的利用这个工具才可以。首先，一定要有一定的测试的理论知识，明白需要采用什么样的数据作为测试用例，那样才能够做到真正好的测试，才能够保证程序的质量。另外，测试代码的编写不是一次就完成了，随着功能的添加，我们的测试代码也一样要随之而改变，在保证原有代码没有问题的前提下，继续编写新的代码。

<!-- [if !supportLists]-->3) <!-- [endif]-->管理人员对开发人员的反馈

这一点看起来似乎不很重要，但是仔细想一想，软件最终的完成靠的是谁呢？这个答案大家应该都非常清楚，其实就是所有的开发人员。没有管理人员一个项目可能会延期完成，或者说质量不高，但是如果没有了开发人员，那么项目是一定不能够完成的。所以，为了保证开发人员的满意度，管理人员对开发人员的意见的反馈是非常重要的。

开发人员在工作的过程中一定会遇到各种各样的问题，比如说休息、待遇、工作的环境、工作使用的工具软件等等，这些问题可能会直接影响到工作的积极性和效率，所以管理人员一定要时刻竖起耳朵来听取这些意见，并及时的进行反馈，避免开发人员带着情绪工作，那样不仅仅会影响到自己，而且由于结对编程的特点，那样的情绪会很快的传遍整个团队，等大家都对当前的项目有了抵触情绪的时候，接下来的结果也就可想而知了。

我想，管理人员的任务就是要将开发人员团结起来，使得所有的人真正成为一个团队，而不是一团散沙。想要做到这一点，就需要时刻了解开发人员的要求，似乎看来他们所做的是类似于后勤的工作，但恰恰是这样的工作往往是最重要的。

<!-- [if !supportLists]-->四、 勇气 <!-- [endif]-->

<!-- [if !supportLists]-->1) <!-- [endif]-->接受任务的勇气

在项目开始的时候，一般的情况是由管理人员来为开发人员分配任务。但是，这种分配只不过是根据管理人员自己心中对每个人的估量来做的，所以很难做到每一个人都很满意。有些时候某些人希望从事自己没有做过的任务，从而学习新的知识；同时还有一些人想要从事自己熟悉的任务，那样可以在更短的时间里面做出更多的成绩。不仅仅是对于每一个人，就是对一个人，可能在不同的时间里面他们的想法都是不一样的，所以说，凭管理人员主观的判断来给大家分配任务一定会有一些人对自己的任务不够满意。

在这个时候，我们不妨尝试这样的一种方法，将所有的任务公布给大家，然后让开发人员自己来选择自己想要做的任务。这样，由于任务是自己选定的，那么满意度会有很大程度上的提高。

在这种情况下，重要的一点就是开发人员要有接受任务的勇气，如果所有的人都选择自己觉得容易的任务，而回避困难的任务，那么我们的方法就失败了，因为必定会有一些任务无人选择。在这个时候，管理人员应该采取适当的方式鼓励开发人员，促使能够选择一些对自己具有挑战性的任务，那样对于个人的提高也是很有好处的。

其实想一想，作为开发人员，应该都不会有问题。勇于迎接挑战，正是现在的程序员大多都具有的一种素质。

转载声明： 本文转自

http://blog.csdn.net/lingyun2005/archive/2005/04/18/352865.aspx

http://blog.csdn.net/lingyun2005/archive/2005/04/27/365384.aspx