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

极限编程的核心有四个，交流、简单、反馈和勇气，这四个原则大家在平时做项目的过程中一定也注意到了。但是两位大师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的集成测试，从而保证代码不会影响到整个系统。

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