eXtreme Programming，极限编程，极限运动之一，玩的就是刺激，玩的就是心跳，据说正被考虑列为奥运会正式比赛项目之一。

以上纯属我自己胡闹。

言归正传，现在的应用软件行业最热门的话题之一就是如何快速高效地生产软件满足客户不断增长的千奇百怪甚至变态的需求，让他们感到满意感到happy。

“客官，您觉得我们的货怎样？”

“嗯，真不错。”

“哟，是吗？那欢迎您以后常来啊！”

然而软件生产不同于一般的产品生产，它不可能totally做到流水线作业，它是个人为主导的活，体现的是人的智慧，它需要充分的思考认真的推敲反复的验证，慢工出细活，越仔细做出的软件才越经得起千锤百炼。但是客户们不愿意等啊，他们才不管你程序写得多棒多优雅是否拿了程序奥斯卡奖，他们要的是尽快地用上软件帮助他们解决问题。

这是个鱼和熊掌难以兼得的问题，一个老生常谈的问题。

于是乎，有人提出了敏捷开发的methodology，eXtreme Programming 就是其中一个非常重要的概念，极限编程秉承敏捷开发的精髓，以优先级为主线，以够用就好（强调了万事无完美这一千百年来的公理），快速而又高效地编写程序，以最快的速度为客户递交软件。敏捷编程主要有如下特点:

1. 完整团队 XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
2. 计划游戏计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。
3. 客户测试作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
4. 简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
5. 结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
6. 测试驱动开发编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。
7. 改进设计随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。
8. 持续集成团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。
9. 集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。
10. 编码标准 系统中所有的代码看起来就好像是被单独一人编写的。
11. 隐喻 将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。
12. 可持续的速度 团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。 极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。

我个人觉得最有意思的是第9条特征，这条十分鲜明地显现了“社会主义集体制”的特点，那就是代码都是属于“人民公社”的，任何人都不得宣称只对某个模块或技术负责，大家都有权利和义务去take care，大家是“集体劳动”，同吃“大锅饭”。我突然脑海里冒出了工农兵的宣传画……

接下来瞅瞅第4条，什么最好？简单最好，“简约而不简单，力郎商务男装”，其实简约二字可能可以更好地解释这一要领，和软件功能恰好匹配，同时表达出设计者的脑袋瓜里所有东西，并且代码优雅量不大质量过硬。设计确实是个很重要的工作，设计者可能很想来个华丽精致的巴洛克风格几近完美，但是那需要庞大的工作量，不符合实际情况，反而现在很多领域里包括fashion，简约之风正在成为时尚。

再看看第7条，这是讲到了内功修炼的阶段，什么是腐化？僵硬（代码无法灵活通用）、脆弱（修改一处代码导致一堆其它问题）、可读性差（哪位大哥写的程序？跟佛经一样难懂），我今天中午还在和一位同事说起这事，说他以前写的某段代码跟垃圾一样，格式丑陋，不写注释，读起来非常费劲，他说其实只要花点时间还是可以读明白的。看见没？典型的麻瓜，我当时真想学哈里.波特用魔术棒把他变成来福。

关于极限编程呢，我理解的就这么多，本人才学疏浅，若有不足之处，还望各位指点。