《敏捷软件开发原则，模式与实践》读书笔记
《敏捷软件开发原则，模式与实践》读书笔记
书名：《敏捷软件开发原则，模式与实践》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隐喻
没有理解这段⽂字

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。