七年等待换来的经典
本书审校：孟岩
Robert C. Martin的经典著作Agile Software Development中文版面世，这是计算机技术出版领域的一件大喜事。即使在今天技术图书市场非常繁荣的局面下，这本书的问世也仍然是值得广大开发者格外留意和关注的事件。这不仅是因为它刚刚荣获2002年度Jolt震撼大奖，更因为这本书本身的价值和独特魅力。
面向对象设计的原则：
1、单一职责原则SRP：就一个类而言，应该仅有一个引起它变化的原因。
2、开放-封闭原则OCP：软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。
3、Liskov替换原则LSP：子类型必须能替换掉它们的基类型。
4、依赖倒置原则DIP：抽象不应该依赖于细节，细节应该依赖于抽象。
5、接口隔离原则ISP：不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
6、重用发布等价原则REP：重用的粒度就是发布的粒度。
7、共同封闭原则CCP：包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其它的包不造成任何影响。
8、共同重用原则CRP：一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
9、无环依赖原则ADP：在包的依赖关系图中不允许存在环。
10、稳定依赖原则SDP：朝着稳定的方向进行依赖。
11、稳定抽象原则SAP：包的抽象程度应该和其稳定程度一致。
第Ⅰ部分 敏捷开发
第一章 敏捷实践
1.1 敏捷联盟
1、个体和交互胜过过程和工具
2、可以工作的软件胜过面面俱到的文档
3、客户合作胜过合同谈判
4、响应变化胜过遵循计划
1.2 原则
1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
3、经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好
4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
5、围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作
6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
7、工作的软件是首要的进度度量标准
8、敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
9、不断地关注优秀的技能和好的设计会增强敏捷能力
10、简单---使未完成的工作量最大化的艺术----是根本的
11、最好的构架、需求和设计出自于自组织的团队
12、每个一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整
1.3 结论
参考文献
第二章 极限编程概述
极限编程（eXtreme Programming 简称XP）是敏捷方法中最著名的一个。它由一系列简单却互相依赖的实践组成。
2.1 极限编程实践
2.1.1 客户作为团队成员
2.1.2 用户素材
2.1.3 短交付周期
1、迭代计划
2、发布计划
2.1.4 验收测试
2.1.5 结对编程
2.1.6 测试驱动的开发方法
2.1.7 集体所有权
2.1.8 持续集成
2.1.9 可持续的开发速度
2.1.10 开放的工作空间
2.1.11 计划游戏
2.1.12 简单的设计
1、考虑能够工作的最简单的事情
在实现当前的用户素材时，如果能够使用平面文件，就不去使用数据库或者EJB（企业级Java Bean)；如果能够使用简单的socket连接，就不去使用ORB对象请求代理或者RMI远程方法调用；如果能够不使用多线程，就别去用它。我们尽量考虑最简单的方法来实现当前的用户素材，选择一种我们能够实际得到的和简单的最接近解决方案的方法
2、你将不需要它
3、一次，并且只有一次
极限编程者不能容忍重复的代码，我们通过定义一个函数或者基类的方法来消除它们。有时两个或者多个算法非常相似，但是之间又存在微妙的差别，我们会把它们变成函数，或者使用Template Method模式，无论是哪一种代码重复之源，一旦发现，就必须被消除，消除重复的最好方法就是抽象。
2.1.13重构
代码会随着一个又一个的特性的添加，一个又一个错误的处理逐渐腐化，代码的结构会逐渐退化，如果对之置之不理，这种退化最终会导致纠结不清，难于维护的混乱的代码。
XP团队通过经常性的代码重构来扭转这种退化。重构就是在不改变代码行为的前提下，对其进行一系列小的改造transfromation，旨在改进系统结构的实践活动。每个改造都是微不足道，几乎不值得去做，但是所有的这些改造叠加在一起，就形成了对系统设计和构架显著的改进。
在每次细微改造之后，我们运行单元测试以确保改造没有造成任何破坏，然后再去做下一次改造。如此往复，周而复始，每次改造之后都要运行测试。通过这种方式，我们可以在改造系统设计的同时，保持系统可以工作。
重构是持续进行的，而不是在项目结束时，发布版本时，迭代结束时，甚至每天快下班时才进行的。重构是我们每隔一个小时或者半个小时就要去做的事情。通过重构，我们可以持续地保持尽可能干净、简单并且具有表现力的代码。
2.1.14 隐喻
隐喻metaphore是所有XP实践中最难理解的一个。极限编程者在本质上都是务实主义者。隐喻是将整个系统联系在一个的全局视图；它是系统的未来景象，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观和整个系统的隐喻不符，那么就知道该模块是错误的。隐喻通常可以归结为一个名字系统。这些名字提供了一个系统组成元素的词汇表，并且有助于定义他们之间的关系。
2.2 结论
第三章 计划
下面的内容是对极限编程XP中计划游戏planning ganme部分的描述。它和在其他敏捷方法，如SCRUM、Crystal、特征驱动开发方法Featrure-Driven Development（FDD）以及自适应软件开发Adaptive Software Development（ADP）中做计划的方式相似。不过这里更详细精确。
3.1 初始探索
3.2 发布计划
3.3 迭代计划
3.4 任务计划
3.5 迭代
3.6 结论
第四章 测试
4.1 测试驱动的开发方法
4.2 验收测试
4.3 结论
第五章 重构
5.1 素数产生程序一个简单的重构示例
5.2 结论
参考文献
第六章 一次编程实践
6.1 保龄球比赛
6.2 结论
第Ⅱ部分 敏捷设计
第七章 什么是敏捷设计
7.1 软件出了什么错
7.2 设计的臭味——腐化软件的气味
7.3 “Copy”程序
7.4 保持尽可能好的设计
7.5 结论
第八章 单一责任原则（SRP）
8.1 单一职责原则（SRP）
8.2 结论
第九章 开放—封闭原则（OCP）
9.1 开放—封闭原则（OCP）
9.2 描述
9.3 关键是抽象
9.4 结论
第十章 Liskov替换原则（LSP）
子类型必须能够替换掉他们的基类型
LSP的违反会潜在地违反OCP
10.1 Liskov替换原则（LSP）
10.2 一个违反LSP的简单例子
10.3 正方形和矩形，更微妙的违规
10.4 一个实际的例子
10.5 用提取公共部分的方法代替继承
10.6 启发式规则和习惯用法
10.7 结论
第十一章 依赖倒置原则（DIP）
11.1 依赖倒置原则（DIP）
11.2 层次化
11.3 一个简单的例子
11.4 熔炉示例
11.5 结论
第十二章 接口隔离原则（ISP）
12.1 接口污染
12.2 分离客户就是分离接口
12.3 接口隔离原则（ISP）
不应该强迫客户依赖于它们不用的方法
12.4 类接口与对象接口
12.5 ATM用户界面的例子
12.6 结论
第Ⅲ部分 薪水支付案例研究
第十三章 COMMAND模式和ACTIVE OBJECT模式
第十四章 TEMPLATE METHOD模式和STRATEGY模式：继承与委托
第十五章 FACADE模式和MEDIATOR模式
第十六章 SINGLETON模式和MONOSTATE模式
第十七章 NULL OBJECT模式
第十八章 薪水支付案例研究：第一次迭×××始
第十九章 薪水支付案例研究：实现
第Ⅳ部分 打包薪水支付系统
第二十章 包的设计原则
第二十一章 FACTORY模式
第二十二章 薪水支付案例研究（第2部分）
第Ⅴ部分 气象站案例研究
第二十三章 COMPOSITE模式
第二十四章 OBSERVER模式——回归为模式
第二十五章 ABSTRACT SERVER模式、ADAPTER模式和BRIDGE模式
第二十六章 PROXY模式和STAIRWAY TO HEAVEN模式：管理第三方API
第二十七章 案例研究：气象站
第Ⅵ部分 ETS案例研究
第二十八章 VISITOR模式
第二十九章 STATE模式
第三十章 ETS框架
附录
附录A UML表示法Ⅰ：CGI示例
附录B UML表示法Ⅱ：统计多路复用器
附录C 两个公司的讽刺小品
附录D 源代码就是设计
索引