《敏捷软件开发》阅读笔记_敏捷软件开发读书笔记

第一章、敏捷实践

1、敏捷联盟宣言

• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

2、在给新的团队成员传授知识方面，最好的两份文档是代码和团队。

3、有许多的敏捷过程可供选择：SCRUM,Crystal，特征驱动软件开发，自适应软件开发，极限编程（XP）

第二章、极限编程概述

1、客户作为团队成员。

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

3、短交付周期。

4、验收测试，一般由自动化脚本构成，不断扩充验收测试集合，并且已经通过测试的功能不允许遭到破坏。

5、结对编程、频繁交换角色、频繁交换伴侣。（感觉有点扯淡）

6、测试驱动开发。

7、集体所有权。没有程序员对任何特定的模块或者技术单独负责。

8、持续集成。（理解为项目始终可编译通过？）

9、可持续的开发速度。XP的规则是不允许团队加班工作（扯），在版本发布前的一星期除外。

10、开放的工作空间。

11、计划游戏。计划游戏不是计划着去游戏，而是做计划是个游戏。本质是划分业务人员和开发人员之间的职责，。业务人员决定特性的重要性，开发人员决定实现一个特性所花费的代价。

12、简单的设计。考虑能够工作的最简单的事情。、

13、重构。XP团队通过经常性的代码重构来扭转这种退化。重构时在不改变代码行为的前提下，对其进行一些列小的改造，旨在改进系统结构的实践活动。重构时我们每隔一个小时或半个小时就要去做的事情。

第五章、重构

1、每一个软件模块都具有三项职责。第一职责是它运行起来所完成的功能。着也是该模块得以存在的原因。第二个职责是它要应对变化。几乎所有的模块在他们的生命周期中都要变化，开发者有责任保证这种改变应该尽可能地简单。一个难以改变的模块是拙劣的，即使能够工作，也需要对它进行修正。第三个职责是要和阅读它的人进行沟通。对该模块不熟悉的开发人员能够比较容易地阅读并理解它。一个无法进行沟通的模块也是拙劣的，同样需要对它进行修正。

2、作者认为提取出函数所增加的可读性是值得花费额外一些微小的性能开销的。然而，也许那些少许的开销存在于深深的内部循环中，这将会造成较大的性能损失。作者的建议是假设这种损失是可以忽略的，等待以后再去证明这种假设是错误的。、

第六章、一次编程实践

1、如果在设计阶段，想要设计的一个类不具有任何行为，可以先不考虑。如果我们去关注那些不仅仅只有setter和getter方法的对象的话，会更有效率。

第七章、什么是敏捷设计

1、软件项目的设计师一个抽象的概念。它和程序的概括形状、结构、以及每一个模块、类和方法的详细形状和结构有关。可以使用不同的媒介去描绘它，但是它最终体现为源代码。最后，源代码就是设计。

第八章、单一职责原则（SRP）

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

1、为何把两个职责分离到单独的类中呢？因为每一个职责都是变化的一个轴线。当需求变化时，该变化会反映为类的职责变化。如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。变化的轴线仅当变化实际发生时才具有真正的意义。如果没有征兆，那么去应用SRP，或者任何其他原则都是不明智的。

2、什么是职责？在SRP中，把职责定义为“变化的原因”。

 

第九章、开放-封闭原则（OCP）

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

1、对于扩展是开放的

模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。换句话说，我们可以改变模块的功能。

2、对于更改是关闭的

对模块的行为进行扩展时，不必改动模块的源代码或二进制代码。模块的二进制可执行版本，无论是可链接的库，dll或者java的.jar文件，都无需改动。

3、无论模块是多么的“封闭”，都会存在一些对之封闭的变化。没有对于所有的情况都贴切的模型。设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。必须猜测出可能发生的变化种类，然后构造抽象来隔离那些变化。

4、开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。

第十章、Liskov替换原则

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

1、如果新派生类的创建会导致我们改变基类，这就常常意味着设计时有缺陷的。

2、正方形和矩形的关系在软件设计当中可能没那么简单。对象的行为方式才是软件真正所关注的问题。LSP清楚地指出，OOD中IS-A关系是就行为方式而言的。

第十一章、依赖倒置原则

a.高层模块不应该依赖于底层模块。二者都应该依赖于抽象。

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

参考:设计模式六大原则例子（四）-- 依赖倒置原则（DIP）例子

1、依赖倒置可以应用于任何存在一个类向另一个类发消息的地方。

第十二章、接口隔离原则（ISP）

不应该强迫客户依赖于它们不用的方法

第十三章、Command模式和Active Object模式

1、Commond模式由一个具有唯一方法的接口组成

2、Active Object模式是一个对象维护了一个Commond对象的链表。

第十四章、Template method模式和Strategy模式:继承和委托

1、Template method模式，把通用算法放置在基类中，并通过继承在不同的具体上下文中实现该通用算法。

2、Strategy不把通用的应用算法放进一个抽象基类中，而是将它放进一个具体类A中，把通用的算法放进接口I中，从这个接口派生出具体的业务类B，然后把B对象作为参数传给A，A就可以把具体工作委托给这个接口去完成。

3、两个模式都可以用来分离高层的算法和低层的具体实现细节。都允许高层的算法独立于它的具体实现细节重用。此外，Strategy模式也允许具体实现细节独立于高层的算法重用，不过要以一些额外的负责性、内存、以及运行时间开销作为代价。

第十五章、FACADE模式和MEDIATOR模式

1、FACEDE模式为一组具有复杂且全面的对象提供一个简单且特定的接口。比如，封装java.sql包，而对外部只提供一个DB类。

2、MEDIATOR模式：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。参考:设计模式之中介者模式（Mediator）

第十五章、SINGLETON模式和Monostate模式

1、singletom模式，参考:C++单例模式的五种实现

2、Momostate模式，把需要实例作为static成员变量，这样即使创建了多个monostate对象，实际使用的还是同一个成员变量。

3、单例模式强制结构上的单一性，防止创建多个对象实例。monostate单态模式强调行为上的单一性。

第十六章、NULL OBJECT模式

1、比如在Employee中创建一个持有唯一NULLEmployee实例的static final变量，并重写其方法。保证即使返回无效的变量也不需要特意第判断是否为NULL。

第二十章、包的设计原则

1、重用的粒度就是发布的粒度。

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

3、一个包不应该包含多个引起变化的原因。

4、在包的依赖关系中不允许存在环

5、对于任何包而言，如果期望它是可变得，就不应该让一个难以更改的包依赖于它。

6、稳定性，稳定性和变化的频率没有直接关系。XXX认为，如果某物不容易被移动，就认为它是稳定的。稳定性和更改所需要的工作量有关。

第二十一章、Factory模式

1、工厂模式允许我们只依赖于抽象接口就能创建出具体对象的实例。