有一个小错误：P67 setUp()写成了steUp()
敏捷宣言
我们一直在实践中揭示更好的软件开发方法，身体力行的同时也帮助他人。
由此，我们建立了如下价值观：
个体和互动 优先于 流程和工具
工作的软件 优先于 详尽的文档
客户合作 优先于 合同谈判
响应变化 优先于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。面向对象设计的原则
SRP 单一职责原则 就一个类而言，应该有且仅有一个引起它变化的原因。
OCP 开放-封闭原则 软件实体（类、模块和函数等）应可以扩展，但不可修改。
LSP 里氏替换原则 子类型必须能替换掉它们的基本类型。
ISP 接口隔离原则 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
DIP 依赖倒置原则 抽象不应该依赖于细节。细节应该依赖于抽象。
REP 重用发布等价原则 重用的粒度就是发布的粒度。
CCP 共同重用原则 一个包中的所有类应该是共同重用的。如果重用包中的一个类，那么就要重用包中的所有类。相互之间没有紧密联系的类不应该在同一个包中。
CRP 共同封闭原则 一个包中所有的类对同一类性质的变化应该是共同封闭的。一个变化若对一个包有影响，就会影响到包中所有的类，但不会影响到其他的包造成任何影响。
ADP 无依赖原则 在包的依赖关系中不允许存在环。细节不应该有其他依赖关系。
SDP 稳定依赖原则 朝着稳定的方向进行依赖。
SAP 稳定抽象原则 一个包的抽象程度应该和其他的保持一致。很多团队迷失在追求文档而非软件上。这通常是个巨大的错误。有条简单的规则称为“文档的马丁第一原则”，意在防止此类错误发生：
除非文档紧急且重要，否则不要写。“大千世界，唯一稀缺的是人类的注意力。”——凯文·凯利（KK）
每个软件模块都有三项职责。第一项职责是运行所完成的功能。这是该模块得以存在的原因。第二项职责是它要应对变化。几乎所有的模块在它们的生命周期中都要变化，开发者有责任保证这种改变应该尽可能简单。一个难以改变的模块是拙劣的，即便能够工作，也需要对它进行修正。第三项职责是要和读的人沟通。对该模块不熟悉的开发人员应该能够轻松地阅读并理解它。一个不能沟通的模块也是拙劣的，同样需要对它进行修正。