一、敏捷联盟宣言html
二、在给新的团队成员传授知识方面，最好的两份文档是代码和团队。java
三、有许多的敏捷过程可供选择：SCRUM,Crystal，特征驱动软件开发，自适应软件开发，极限编程（XP）程序员
一、客户做为团队成员。算法
二、用户素材。就是正在进行的关于需求谈话的助记符。它是一个计划工具，客户可使用它并根据它的优先级和估算代价来安排实现该需求的时间。sql
三、短交付周期。编程
四、验收测试，通常由自动化脚本构成，不断扩充验收测试集合，而且已经经过测试的功能不容许遭到破坏。设计模式
五、结对编程、频繁交换角色、频繁交换伴侣。（感受有点扯淡）函数
六、测试驱动开发。工具
七、集体全部权。没有程序员对任何特定的模块或者技术单独负责。性能
八、持续集成。（理解为项目始终可编译经过？）
九、可持续的开发速度。XP的规则是不容许团队加班工做（扯），在版本发布前的一星期除外。
十、开放的工做空间。
十一、计划游戏。计划游戏不是计划着去游戏，而是作计划是个游戏。本质是划分业务人员和开发人员之间的职责，。业务人员决定特性的重要性，开发人员决定实现一个特性所花费的代价。
十二、简单的设计。考虑可以工做的最简单的事情。、
1三、重构。XP团队经过常常性的代码重构来扭转这种退化。重构时在不改变代码行为的前提下，对其进行一些列小的改造，旨在改进系统结构的实践活动。重构时咱们每隔一个小时或半个小时就要去作的事情。
一、每个软件模块都具备三项职责。第一职责是它运行起来所完成的功能。着也是该模块得以存在的缘由。第二个职责是它要应对变化。几乎全部的模块在他们的生命周期中都要变化，开发者有责任保证这种改变应该尽量地简单。一个难以改变的模块是拙劣的，即便可以工做，也须要对它进行修正。第三个职责是要和阅读它的人进行沟通。对该模块不熟悉的开发人员可以比较容易地阅读并理解它。一个没法进行沟通的模块也是拙劣的，一样须要对它进行修正。
二、做者认为提取出函数所增长的可读性是值得花费额外一些微小的性能开销的。然而，也许那些少量的开销存在于深深的内部循环中，这将会形成较大的性能损失。做者的建议是假设这种损失是能够忽略的，等待之后再去证实这种假设是错误的。、
一、若是在设计阶段，想要设计的一个类不具备任何行为，能够先不考虑。若是咱们去关注那些不只仅只有setter和getter方法的对象的话，会更有效率。
一、软件项目的设计师一个抽象的概念。它和程序的归纳形状、结构、以及每个模块、类和方法的详细形状和结构有关。可使用不一样的媒介去描绘它，可是它最终体现为源代码。最后，源代码就是设计。
就一个类而言，应该仅有一个引发它变化的缘由。
一、为什么把两个职责分离到单独的类中呢？由于每个职责都是变化的一个轴线。当需求变化时，该变化会反映为类的职责变化。若是一个类承担了多于一个的职责，那么引发它变化的缘由就会有多个。变化的轴线仅当变化实际发生时才具备真正的意义。若是没有征兆，那么去应用SRP，或者任何其余原则都是不明智的。
二、什么是职责？在SRP中，把职责定义为“变化的缘由”。
软件实体（类，模块，函数等等）应该是能够扩展的，可是不可修改的。
一、对于扩展是开放的
模块的行为是能够扩展的。当应用的需求改变时，咱们能够对模块进行扩展，使其具备知足那些改变的新行为。换句话说，咱们能够改变模块的功能。
二、对于更改是关闭的
对模块的行为进行扩展时，没必要改动模块的源代码或二进制代码。模块的二进制可执行版本，不管是可连接的库，dll或者java的.jar文件，都无需改动。
三、不管模块是多么的“封闭”，都会存在一些对之封闭的变化。没有对于全部的状况都贴切的模型。设计人员必须对于他设计的模块应该对哪一种变化封闭作出选择。必须猜想出可能发生的变化种类，而后构造抽象来隔离那些变化。
四、开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象。拒毫不成熟的抽象和抽象自己同样重要。
子类型必须可以替换掉他们的基类
一、若是新派生类的建立会致使咱们改变基类，这就经常意味着设计时有缺陷的。
二、正方形和矩形的关系在软件设计当中可能没那么简单。对象的行为方式才是软件真正所关注的问题。LSP清楚地指出，OOD中IS-A关系是就行为方式而言的。
a.高层模块不该该依赖于底层模块。两者都应该依赖于抽象。
b.抽象不该该依赖于细节。细节应该依赖于抽象。
参考:设计模式六大原则例子（四）-- 依赖倒置原则（DIP）例子
一、依赖倒置能够应用于任何存在一个类向另外一个类发消息的地方。
不该该强迫客户依赖于它们不用的方法
一、Commond模式由一个具备惟一方法的接口组成
二、Active Object模式是一个对象维护了一个Commond对象的链表。
一、Template method模式，把通用算法放置在基类中，并经过继承在不一样的具体上下文中实现该通用算法。
二、Strategy不把通用的应用算法放进一个抽象基类中，而是将它放进一个具体类A中，把通用的算法放进接口I中，从这个接口派生出具体的业务类B，而后把B对象做为参数传给A，A就能够把具体工做委托给这个接口去完成。
三、两个模式均可以用来分离高层的算法和低层的具体实现细节。都容许高层的算法独立于它的具体实现细节重用。此外，Strategy模式也容许具体实现细节独立于高层的算法重用，不过要以一些额外的负责性、内存、以及运行时间开销做为代价。
一、FACEDE模式为一组具备复杂且全面的对象提供一个简单且特定的接口。好比，封装java.sql包，而对外部只提供一个DB类。
二、MEDIATOR模式：用一个中介对象来封装一系列的对象交互。中介者使各对象不须要显式地相互引用，从而使其耦合松散，并且能够独立地改变它们之间的交互。参考:设计模式之中介者模式（Mediator）
第十五章、SINGLETON模式和Monostate模式
一、singletom模式，参考:C++单例模式的五种实现
二、Momostate模式，把须要实例做为static成员变量，这样即便建立了多个monostate对象，实际使用的仍是同一个成员变量。
三、单例模式强制结构上的单一性，防止建立多个对象实例。monostate单态模式强调行为上的单一性。
一、好比在Employee中建立一个持有惟一NULLEmployee实例的static final变量，并重写其方法。保证即便返回无效的变量也不须要特地第判断是否为NULL。
一、重用的粒度就是发布的粒度。
二、一个包中的全部类应该是共同重用的。若是重用了包中的一个类，那么就要重用包中的全部类。
三、一个包不该该包含多个引发变化的缘由。
四、在包的依赖关系中不容许存在环
五、对于任何包而言，若是指望它是可变得，就不该该让一个难以更改的包依赖于它。
六、稳定性，稳定性和变化的频率没有直接关系。XXX认为，若是某物不容易被移动，就认为它是稳定的。稳定性和更改所须要的工做量有关。
一、工厂模式容许咱们只依赖于抽象接口就能建立出具体对象的实例。