《敏捷软件开发原则，模式与实践》读书笔记

书名：《敏捷软件开发原则，模式与实践》agile software development principles,patterns,and practices

作者：Robert C.Martin

敏捷软件开发宣言

我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：

个体和交互 胜过 过程和工具

可以工作的软件 胜过 面面俱到的文档

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

虽然右项也具有价值，但我们认为左项具有更大的价值。

敏捷宣言遵循的原则

我们遵循以下原则：

1）我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

2）即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3）经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

4）在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5）围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6）在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

7）工作的软件是首要的进度度量标准。

8）敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

9）不断地关注优秀的技能和好的设计会增强敏捷能力。

10）简单---使未完成的工作最大化的艺术---是根本的。

11）最好的架构、需求和设计出自于自组织的团队。

12）每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应的对自己的行为进行调整。

面向对象设计的原则

SRP 单一职责原则

就一个类而言，应该仅有一个引起它变化的原因。

OCP 开发-封闭原则

软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。

LSP Liskov替换原则

子类型必须能够替换掉它们的基类型。

DIP 依赖倒置原则

抽象不应该依赖于细节。细节应该依赖于抽象。

ISP 接口隔离原则

不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。

REP 重用发布等价原则

重用的粒度就是发布的粒度

CCP 共用封闭原则

包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。

CRP 共同重用原则

一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中所有类。

ADP 无环依赖原则

在包的依赖关系图中不允许存在环。

SDP 稳定依赖原则

朝着稳定的方向进行依赖。

SAP 稳定抽象原则

包的抽象程度应该和其稳定程度一致。

极限编程实践

完整团队

XP项目的所有参与者（开发人员、业务分析师、测试人员等等）一起工作在一个开放的场所中，他们是同一个团队的成员。

计划游戏

计划是持续的，循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

客户测试

作为选择每个所期望的特性的一部分，客户定义出自动验收测试来表明该特性可以工作。

简单设计

团队保持设计恰好和当前的系统功能相匹配，它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

结对编程

所有的产品软件都是由两个程序员，并排坐在一起在同一台电脑上构建的。

测试驱动开发

程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

改进设计

随时改进糟糕的代码。保持代码尽可能的干净，具有表达力。

持续集成

团队总是使系统完整地被集成。

集体代码所有权

任何结对的程序员都可以在任何时候改进任何代码。

编码标准

系统中所有的代码看起来就好像是被单独一个--非常值得胜任的--人编写的。

隐喻

团队提出一个程序工作原理的公共景像。

可持续的速度

团队只有持久才有获胜的希望，他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长袍，而不是全速短跑。

第一部分 敏捷开发

第一章 敏捷实践

1.2原则

1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3.经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5.围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。

6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交流。

7.工作的软件是首要的进度度量标准。

8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

9.不断地关注优秀的技能和好的设计会增强敏捷能力。

10.简单--使未完成的工作最大化的艺术---是根本的

11.最好的架构、需求和设计出自于自组织的团队。

12.每隔一定时间。团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

第2章 极限编程概述

2.1极限编程实践

极限编程（eXtreme Programming,简称XP）是敏捷方法中最著名的一个。它由一系列简单却相互依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。

2.1.1客户作为团队成员

我们希望客户和开发人员在一起紧密地工作，以便于彼此知晓对方所面临的问题，并共同去解决这些问题。

XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团队。客户包括：和开发人员同属一家公司的一组业务分析师或者市场专家；用户代表；支付开发费用的人。

最好的情况是客户和开发人员在同一个房间中工作，次一点的情况是客户和开发人员之间的工作距离在100米以内。距离越大，客户就越难成为真正的团队成员。

2.1.2用户素材

为了进行项目计划，必须要知道和项目需求有关的内容，但是却无需知道得太多。对于做计划而言，了解需求只需要做到能够估算它的程度就足够了。你必须要知道存在很多细节，也必须要知道细节的大致分类，但是你不必知道特定的细节。

需求的特定细节很可能会随时间而改变，因此在离真正实现需求还很早时就去捕获该需求的特定细节，很可能会倒置做无用功以及对需求不成熟的关注。

在XP中，我们和客户反复讨论，以获取对于需求细节的理解，但是不去捕获那些细节。我们更原意客户在索引卡片上写下一些我们认可的词语。这些词语可以提醒我们记起这次交谈。基本上在和客户进行书写的同以时刻，开发人员在该卡片上写下对应于卡片上需求的估算。估算是基于和客户进行交谈期间所得到的对于细节的理解进行的。

用户故事就是正在进行的关于需求谈话的助记符。它是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。

2.1.3 短交付周期

XP项目每两周交付一次可以工作的软件。每两周的迭代都实现了客户的一些需求。在每次迭代结束时，会给客户演示迭代生成的系统，以得到他们的反馈。

1.迭代计划

每次迭代通常耗时两周。这是一次较小的交付，可能会被加入到产品中，也可能不会，它由客户根据开发人员确定的预算而选择的一些用户故事组成。

开发人员通过度量在以前的迭代中所完成的工作量来为本次迭代设定预算。只要估算成本的总量不超过预算，客户就可以为本次迭代选择任意数量的用户故事。

一旦迭代开始，客户就统一不再修改档次迭代中用户故事的定义和优先级别。迭代期间，开发人员自由的将用户故事分解成task，并一句最具技术和商务意义的顺序来开发这些task。

2.发布计划

XP团队通常会创建一个计划来规划随后大约6次迭代的内容，这就是所谓的发布计划。一次发布通常需要3个月的工作。它表示了一次较大的交付，通常此次交付会被加入到产品中。发布计划是由一组客户根据开发人员给出的预算所选择的、牌号优先级别的用户素材组成。

发布计划不是一成不变的，客户可以随时改变计划的内容。

2.1.4验收测试

可以以客户指定的Acceptance Tests的形式来捕获有关用户素材的细节。用户素材的验收测试是在就要实现该用户故事之前或者实现该用户故事的同时进行编写的。

验收测试使用能够让它们自动并且反复运行的某种脚本语言编写，这些测试共同来验证系统按照客户指定的行为运转。

一旦通过一项验收测试，就将该测试加入到已经通过的验收测试集合中，并决不允许该测试再次失败。这个不断增长的验收测试计划每天会被多次运行，每次系统被创建时，都要运行这个验收测试集。

所有的产品代码都是由结对的程序员使用同一台多年共同完成的。结对人员中的一个控制键盘并输入代码，另一位观察输入的代码并寻找着代码中的错误和可以改进的地方。

两个人频繁互换角色，最终生成的代码是由他们两人共同设计，共同编写的。

结对的关系每天至少要改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。在一次迭代期间，每个团队成员应该和所有其他的团队成员在一起工作过，并且他们应该参与了本次迭代中所涉及的每项工作。

这将极大地促进知识在团队中的传播。

2.1.6测试驱动的开发方法

2.1.7集体所有权

2.1.8持续集成

2.1.9可持续的开发速度

XP的规则是不允许团队加班工作。在版本发布前的一个星期是该规则的唯一例外。

2.1.10开放的工作空间

2.1.11计划游戏

planning game 的本质是划分业务人员和开发人员之间的职责。业务人员（客户）决定特性的重要性，开发人员决定实现一个特性所花费的代价。

2.1.12简单的设计

XP团队使他们的设计尽可能地简单，具有表现力。此外，他们仅仅关注了计划在本次迭代中要完成的用户故事。

这意味着XP团队的工作可能不会从基础结构开始，他们可能并不先去选择使用数据库或者中间件。团队最开始的工作是以尽可能最简单的方法实现第一批用户故事。只有当出现一个用户故事迫切需要基础结构时，他们才会引入该基础结构。

下面有三条XP指导原则：

1.考虑能够工作的最简单的事情

XP团队总是尽可能寻找能实现当前用户故事的最简单的设计。

2.你将不需要它

3.一次，并且只有一次

极限编程者不能容忍重复的代码。无论在哪里发现重复的代码，他们都会消除它们。

2.1.13重构

代码往往会腐化，随着我们添加一个又一个的特性，处理一个又一个的错误，代码的结构会逐渐退化。

重构就是在不改变代码行为的前提下，对其进行一系列小的改造，旨在改进系统结构的实践活动。

重构是持续进行的。

2.1.14隐喻

没有理解这段文字