挑战极限—极限编程中的“极限”

最近，一直在看Robert Martin的《敏捷软件开发—原则、模式和实践》，该文中以极限编程（XP）来讲述敏捷的实践。看完有关于XP实践的部分，对XP基本的主张和如何去实践有了一个大概的了解。但是，一直有个问题在我脑海中，那就是这种开发实践方式为什么会被称为“极限编程”？看完这部分之后，对这个问题只有一些模模糊糊的理解，并没有明确的答案。于是，又找到Kent Beck的《解析极限编程—拥抱变化》。对过对这两本书的阅读，上述的那个问题的答案似乎逐渐清晰。所以在这里，谈一下自己对极限编程的极限的理解。

极限编程之所以被称为极限，我认为是源自于它的设计哲学，那就是将大家公认的好的东西做到极致。它所倡导的实践就是将大家公认为好的实践努力做到最好。我们可以从它所主张的实践来分析它的“极限”意义。首先，极限编程的具体实践包括：完整团队、计划游戏、客户测试、简单设计、结对编程、测试驱动开发、重构、持续集成、集体代码所有权、编码标准、隐喻和可持续的速度。

敏捷宣言里有一条：客户合作胜过合同谈判，所以对敏捷来说，客户合作是好的。既然客户合作是好的，极限编程就要把这种合作做到最紧密，主张将客户作为团队的成员来决定业务优先级。这就是所谓的“完整团队”。

由于人的思维惯性和程序员的乐观主义，任何开发方法都强调要进行代码评审。所以，代码评审是好的。极限编程就把代码评审做到极致，每一行代码产生的时候就进行了评审。这就是结对编程，两个开发人员对着一台电脑开发。

测试时保证系统质量的强大武器，所以测试是好的。极限编程就把测试的作用发挥到极限，于是就要求始终测试，包括单元测试和功能测试。而且测试先行，测试先行，当实现某个功能时，先写一个原有程序不能通过的测试，然后实现该功能，使之能通过该测试。这就是客户测试和测试驱动开发。

软件开发中，设计的重要性是不言而喻的。既然设计这么重要，极限编程就要求把设计当做每个人日常事务的一部分，当做最重要的工作。所以主张不停地重构，去调整代码结构、去除冗余代码，使设计结构清晰、代码简洁。

敏捷主张简单设计。既简单是好的，极限编程就保证系统设计永远是最简单的，于是始终把系统保持为支持其当前功能的最简单设计。极限编程只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。

系统的体系结构是系统的骨架，对整个系统起决定性作用。所以体系结构是非常重要的，极限编程就要求所有人不断地进行定义和完善体系结构的工作，并提供系统组成的元素的词汇表，这个词汇表就是系统的隐喻。

单元测试只是针对某个功能，但一个系统不是简单的功能叠加，其中涉及到很多通信与协作，这就需要集成测试。所以集成测试是好的。极限编程就增加集成测试的密度，那在一天内多次集成测试，并针对每一个功能做集成。这就是要持续集成。

敏捷认为，交付越频繁，最后交付的软件质量就越高。要提高交付密度，就需要缩短迭代周期。所以迭代周期短是好的。极限编程主张将迭代时间放到尽可能的短。一般而言，两周一个迭代是比较合适的。

从上述实践，我们不难得知，极限编程就是在挑战极限！