重构极限编程：XP的实践与反思

　　在开始之前，我们想请读者注意本书一些非常独特的元素。这不是一本普通的，一般性的计算机科学类的书籍！ 我们感觉这样一个主题适合采用讽刺的手法，因此我们下决心赋予它这样的风格。除讽刺之外，还有许多冷静的幽默。我们有时确实变得严肃，并对了极限编程（XP）固有缺陷和危险进行认真的系统分析。说到这一点，这本书并非完全“抨击”XP的一部著作。正如后面指出的，不是所有XP都是糟糕的。我们打算提供一个中肯的批评，并指出XP中可以被抢救或重构的部分，以更加健壮的方式实现同样敏捷的目标。XP受到了名不副实的炒作，并且新的XP书籍继续以难以置信的速度出版。围绕XP恶性膨胀的呼声从各方面影响了产业界（有些是正面的，如同我们探求的，但大多数是负面的）。有鉴于此，我们感觉一本逆着XP浪潮，抵制XP的书是重要的。这里有一个小例子，说明XP如何影响业界。Matt（本书勇敢无畏的共同作者）收到来自一位顾问的电子邮件，这位顾问最近失去了一份重要合同，因为他拒绝在没有首先进行一些详细的需求分析和预先设计之前启动项目。客户通过阅读知道XP编程，他告诉那位顾问：“即然XP认为以那种方式启动项目没有问题，那么我们将找到跳过需求和预先设计而直接启动项目的人！” 虽然一些业务人员听说XP后，立刻陷入疯狂（像上面的顾问故事提示的那样），但仍有一些人立场坚定，拒绝变化。实际上，想要将XP引入其组织的团队面对的一个主要问题是，XP要求在整个组织中有显著的思想改变，从团队的组织方式到公司与客户做业务的方式。本书分析了XP的缺点，并提出一种可选择的实现敏捷性的方法，与XP相比，它对现有组织要求少得多的变化，同时仍然保留了XP的敏捷目标。您能使用这一“可选择的方法”作为蓝本来设定自己的敏捷方法学（本书临近结尾处提供了一些指针，指向我们感觉比XP更为严谨的其它敏捷过程）。然而，本书最重要的目的是打碎一些紧随XP浪潮开始出现的神话，譬如无需记录工作的神话，一位现场客户和一些自动化测试足以替代书面需求规范的神话，以及个人的需要和舒适是项目次要元素的神话（即，“和我们结对编程或另谋高就”）等。并且我们打算以娱乐和幽默的方式来实现我们的目的，因为……很好，因为相关的主题要求这样。读者对象： XP经常由程序员引入组织。这毫不奇怪，因为XP是“对程序员非常友好的”方法。它提升了程序员的作用（本质上不是一件坏事），并把他们置于与客户齐舞的水平。因此，如果您是经理或客户，正被兜售在下一个项目中使用XP的想法，本书提供了一个颇有价值的反面观点。如果您是将XP引入组织的程序员，本书应该对您有所帮助，因为它概述了XP的许多危险，它们可能是潜在的项目杀手，而这些危险在其他有关XP的书籍中倾向于被一带而过。如果您正在考虑剪裁XP以提取它的所有长处，但又想避免“多末诺骨牌”效应，也就是说，避免过程的一个小的变化引起整个过程崩溃，这本书提供了一些可贵的指导。

暂缺《重构极限编程：XP的实践与反思》作者简介

第Ⅰ部分  另一个美好的混乱第1章  疯狂的XP 11.1  理论上的极限编程 21.1.1  XP的中心前提 21.1.2  价值 31.1.3  实践 41.1.4  活动 111.1.5  角色 131.1.6  XP的生命周期 141.2  XP面向什么问题 151.2.1  典型软件项目中反映出的什么问题可以作为XP的目标 151.2.2  现有方法学中还有哪些问题可以作为XP的目标 161.3  实践中的极限编程: XP实际经历的评价 161.4  先拆下，后重建 191.4.1  价值 191.4.2  活动 191.4.3  其他要素 201.5  小结 20第2章  XP诞生于何处 222.1  C3概述 242.2  XP项目的生命周期(如C3的活动所展示) 242.2.1  大肆宣传和吹嘘 252.2.2  做可能实现的最简单的事 272.2.3  产生一个快速成功的错觉 272.2.4  无休止的重构 292.2.5  放弃发货! 302.2.6  取消 312.2.7  胜利和成功的声明 322.2.8  新闻组中的困惑 342.2.9  声明它并不那么重要 372.3  C3的问题 392.3.1  现场客户的工作过于艰难 402.3.2  厨师太多 402.3.3  逐渐增加得不够 412.3.4  开发人员偏离了正确路线 412.4  小结 42第3章  反XP案例 433.1  一个自反安全网络(蛇圈) 433.1.1  从合作衍变为象征意义(symbolism) 443.1.2  生命周期还是蛇圈 473.1.3  把蛇拆散开 503.1.4  将蛇捆绑在一起：部分的XP 593.2  因此制宜XP颠倒的原因 603.2.1  逻辑性与情绪化 613.2.2  把您的鸭子固定成一排 633.3  小结 64第Ⅱ部分  XP的社会效应第4章  Extremo文化 654.1  "XP不是无节制的删减！” 664.1.1  为什么XP实践者们觉得XP不是真的删减 664.1.2  把文档丢给狮子 674.1.3  为什么在开始编码前详细记录设计 674.2  XP进入主流 684.2.1  XP实践者不做设计 694.2.2  XP实践者不编写文档 704.2.3  主流世界中的XP 704.3  XP和.com的繁荣 714.4  XP作为人的过程 734.4.1  敏捷过程中的“嬉皮士“ 734.4.2  IfXPIsntWorkingYoureNotDoingXP 744.4.3  把人的过程极端化 754.4.4  XP和点心 764.4.5  XP宣言：再多些奶酪，伙计？ 774.5  XP术语 784.6  像Constantinople和TerminationCanbeSuccess 这样的长词 794.7  向发信人攻击 814.8  恐惧 844.8.1  恐惧和Extremo文化 854.8.2  恐惧和Extremos 854.8.3  恐惧是C3失败的原因吗 884.8.4  如果您没在做XP，那么您一定是害怕了 894.9  小结 90第5章  现场客户 915.1  那是客户的问题 925.2  现场客户：旧约 945.2.1  “旧约”现场客户的问题 955.2.2  现场客户的问题促使C3项目失败吗 965.2.3  警告：当一名现场客户可能对健康有害 975.3  现场客户：新约 995.3.1  我们能对XP客户团队有何期望 995.3.2  厨师太多 1005.3.3  接受度测试 1015.3.4  没有安全保障网络 1025.4  小结 103第6章  结对编程 1046.1  结对编程基础 1056.2  有项研究能证实我的观点 1076.3  为沉默的声音祈求 1116.4  这是一种爱的工作，却要用强迫的手段来实行 1126.5  生产率：程序员数量/2==程序员数量 1146.6  结对编程说明 1216.6.1  不同类型的程序员的结对问题 1216.6.2  其他问题 1236.6.3  小心，桌子底下有蛇! 1246.7  小结 125第7章  口头文档 1267.1 “但是我以为您的意思是……" 1277.1.1  需求文档 1277.1.2  设计文档 1297.2  只是无知的白痴 1327.2.1  在其位，谋其政 1337.2.2  仅稍稍超前他的时代 1337.2.3  专题小组的成员们脱离了现实 1357.2.4  别打扰我，我正忙着-- 去看录像带吧 1357.2.5  项目过程中被雇佣的新程序员会怎样呢 1367.2.6  单元测试是文档(是的，很对) 1377.3  小结 140第Ⅲ部分  无需永久性的规范和预设计第8章  先测试后设计 1428.1  当只有锤子时 1438.2  XP设计的口头禅：没有BDUF 1468.3  单元测试的问题 1478.3.1  面向异步消息传递和多线程系统的测试 1478.3.2  其他问题 1498.3.3  单元测试很简单-- 客户需要编写那些令人讨厌的接受度测试 1508.3.4  没有安全网的编程 1568.4  小结 158第9章  编程后的持续重构 1599.1  重构的天堂 1619.2  XP设计的口头禅：残忍地重构 1639.2.1  当重构有用时 1659.2.2  当重构变得简短时 1669.3  预先设计能否完全避免后来的重大重构 1699.3.1  代码真的就是设计吗 1699.3.2  预先设计真的是一件坏事吗 1709.3.3  进行多少预先设计才足够 1729.4  在固定的用户库下进行重构 1749.4.1  不间断的全面维护 1759.4.2  惹恼用户：重构实际的用户界面 1769.4.3  的确惹恼了用户：破坏了他们的真实数据 1779.5  小结 180第10章  用户故事和接受度测试 18110.1  爸爸，给我讲个故事 18210.2  用户故事与用例 18510.2.1  用例 18610.2.2  什么是用例驱动的开发 18610.2.3  用例要比故事更严格 18810.3  用户故事与需求 18910.3.1  需求 18910.3.2  在非XP项目中，不确定的需求是怎么处理的 19110.3.3  体系结构变化的需求 19310.4  作为接受度测试的“文档化”需求 19310.5  小结 196第Ⅳ部分  永久编码机第11章  软件开发无止境 19711.1  进度表本身并不存在 19811.1.1  拒绝已完成的概念 19811.1.2  拥抱蔓延的项目需求范围渐变 20111.1.3  如果不知道项目完成期限 20411.2  范围可变的合同 20711.3  小结 213第12章  紧急结构和设计 21412.1  XP设计的咒语：YAGNI 21912.2  构建紧急设计的基础构造 22112.1  代码有设计价值而没有商业价值 22312.3  紧急结构与早期原型 23212.4  小结 234第13章  拥抱变化 23513.1  变更成本曲线(修改错误成本的曲线) 23713.2  早期发布，经常发布 23913.3  发布计划 24113.4  迭代计划 24213.5  永久编码机(拥抱变化) 24313.5.1  故事变更 24413.5.2  敏捷意味着快速吗 24413.5.3  设计变更 24513.6  变化是什么 24713.7  使用预先设计来增强敏捷性 24813.7.1  管理变化 24813.7.2  设计抽象的平衡 24913.8  小结 251第Ⅴ部分  全  局  图第14章  可伸缩性 25214.1  问题描述：在50人的项目中使用XP方法 25314.1.1  避开实践 25414.1.2  ATLAS规模大小项目中的紧急设计 25714.1.3  结论 25814.2  体系结构的可伸缩性 25914.2.1  可伸缩性驱动体系结构 26014.2.2  Extreme Programming Installed中的例子：病人记录数据库 26014.3  当XP开始失效时 26414.3.1  手写故事卡和口头文档 26514.3.2  集体所有权 26514.3.3  XP教练 26514.3.4  现场客户 26614.3.5  公共编码房间 26614.3.6  紧急结构 26714.4  小结 269第15章  重构XP 27015.1  如何既敏捷又不脆弱 27115.1.1  良好的敏捷过程应该减少风险 27215.1.2  良好的敏捷过程应该支持应急 27215.1.3  良好的敏捷过程应该避免脆弱性 27315.2  拔掉极限编程的毒牙：除去XP中的“极限” 27515.2.1  重构XP实践/ Xtudes /价值/原则 27515.2.2  附加实践 28615.2.3  交互设计师 28715.3  案例研究：服务器工具项目 28915.3.1  概述 28915.3.2  XP能满足需要吗 29015.3.3  框架 29215.3.4  不止一个雇主 29315.4  小结 294第16章  结论：消除事实曲解的地方 29516.1  运用中的无形技巧 29616.1.1  太多琐碎的讨论 29616.1.2  微妙玄通，深不可识 29716.1.3  差建议就是差建议 29816.2  在结束之时 30216.3  结束语 304