浅析《极限编程XP丛书》

　　首次接触这个极限编程的概念是在软件工程课堂上，在了解了瀑布模型、快速原型模型、螺旋模型等一系列比较系统化和规范化的模型之后，老师又讲到了敏捷过程，课本上的介绍很简练，没有过多复杂的图示，总结起来就是这个方法具有人性化、交互性强、灵活性高、没有复杂冗余的文档等特点。于是我对这种敏捷的方法产生了兴趣，便在图书馆找到了两本书名为《极限编程实施》和《探索极限编程》，阅读后开始更深刻地了解极限编程，也更深刻地了解了软件工程这门学科。

　　首先，阅读过程中我带着书上四点关于极限编程的特点进行阅读，条理更加清晰明了，并且结合以上两本书的具体例子更加深入人心，特点如下：

1、开发人员的素质及互相间的交互与协作比过程和工具更重要。

2、可以工作的软件比面面俱到的文档更加重要。

3、与客户的合作比合同谈判更重要。

4、及时响应变化比死板地遵循计划更重要。

　　在阅读全书之后我又根据极限编程的独有的特点总结出了以下几个关键词：客户与程序员，客户故事，迭代规划，编码测试。

一、客户与程序员

　　在极限编程中独特地要求客户最好与程序员全天候地待在一起，因为项目是在客户和程序员的协作指导下走向成功的，XP(极限编程)团队希望越快越好，XP的简单性有助于实现这种目标。编写书面形式的规范需要的时间长，且不利于沟通，容易产生歧义。随着项目的进程，口头交流需求则要有效得多，如果客户现场参与工作，既节省了时间和开销，又在客户和程序员之间建立起一种和谐的关系，这种关系将有助于公司克服以后可能面临的任何困难。

　　有人可能会怀疑，客户难道没有自己的工作吗？OK,公司可以在开发区域内设置办公场所，可以使用计算机，大多数情况下他们做自己的常规性工作，并且回答几个问题，但是他们回答的几个问题能很有效地消除程序员关于需求和代码的猜测，你难道希望代码中有大多数的猜测吗？

　　总而言之，让客户参与现场具有实质性的价值而不是走过场，很多程序员的疑问可以瞬间解决而不是等对方遥遥无期的e-mail回复，极大地提高了工作速度和效率。

二、客户故事和迭代规划

　　软件的生命周期为：定义、估算、选择、构建。

　　在一个XP项目中，客户通过写故事的形式定义业务价值，而程序员要实现这些故事，创建业务价值，且应按照客户的要求去做，XP的分析是从故事开始的，XP分析工具包是一包空白卡片，选择一个舒适的地方让几个客户和几个程序员同座一桌工作，并给每个人发一些卡片用笔进行测试填写故事，大多数用户提出的故事，程序员知道如何在一周左右的时间内实现他们，而有的故事则稍显复杂，可以与客户讨论能否将该故事分割。

　　用户故事其实是由两部分组成。书面卡片是第一部分，XP建议书写故事时仅用一两句话，并指出任何支持性文档。第二部分也是目前为止最重要的一部分，是在完成故事编写时发生在程序员和客户会减的一系列对话。每个故事卡片都贯穿于项目始终，一旦需要可供规划和实施时参考。因此，程序员必须能够合理地估算每个故事的难度，这样才能进行后面的迭代规划。

　　迭代规划中又有三个关键步骤：

1、客户提出用户故事。

2、团队集体讨论工程任务。

3、程序员选定任务并作出估算。

　　前两点还是在强调客户与程序员的交流，这里边不再赘述，第三点选择任务则比较重要。程序员自己选定工作，要选出自己认为可以再改迭代（小的程序块）期间完成的工作量，对其作出估算，并且在工作过程中对其进行追踪。最好选择故事中的全部任务而不是挑选其中的某些任务，这样可以确保故事的完整实现，而且在实现的时候也不会互相拖延，因为每个人的工作任务优先级是不同的故可能产生相互等待。

三、编码测试

1、结对编程

　　XP所有生产代码的方式都是由两人同在一台电脑前完成的，将这种编程方式称为结对编程，结对编程是两个程序员肩并肩地坐着，一起编写程序。输入代码的程序员称为四级，另一位程序员称为伙伴，伙伴不是闲坐着而是积极地参与并且提供帮助。司机在长时间的编码输入后会产生部分错误，此时则要求伙伴负责纠正简单的错误例如拼写和标点，并且提醒他代码的格式要符合团队标准，并保证对代码的测试。工作过程中，二人小组首先要书写测试代码，然后进行调试以使其正常运行。必要时司机可与伙伴交换角色可以免于代码的死板。

2、简单设计和重构

简单设计应该满足下列要求：1、运行所有的测试。2、清楚地表达了你需要表达的思想。3、不含有重复的代码4、拥有最少量的类和方法的数量。

　　为了保持代码的简单性，我们必须要了解并擅长重构，重构是一种过程，它改善了代码的结构同时维持了其功能，过程中应当每一个步骤都是可逆的所以可以进行尝试，如果不喜欢所得结果，可以向前返回，该过程可以培养对于代码的好奇心和尝试及学习的态度。通过重构可以循序渐进地创建系统，既能侧重于业务价值，又无须担心过早作出的错误决定。

3、代码标准

以下是XP标准中的一些主要内容：缩进、大写、注释、方法的大小、名称（这里我只是概括，不然篇幅太长）。

PS：在测试方面由于经验较少，就不进行讨论以免出现啼笑皆非的错误。

　　在阅读两书之后，我对软件工程这门学科也有了更深的见解，软件工程更强调的是我们对开发软件方面各个流程的规范化和科学化而不是教我们怎样编写代码，意在教我们如何高效地利用短时间来实现最大的业务价值，并且在开发工程的同时不断地改进自我提升自我。

以上便是我对极限编程区别于其他软件工程方法的个人见解和对软件工程课程的感触，如有不妥之处希望与大家交流改进。