敏捷软件开发：原则、模式与实践 第七至九章读书笔记

第七章 敏捷设计

拙劣设计的症状定义:

1. 僵化性(Rigidity): 设计难以改变
   对软件进行一个单一改动，却引发一系列有依赖关系模块的连锁改动
2. 脆弱性(Fragility): 设计易于遭到破坏
   对软件进行单一改动时，程序的许多其他地方就会出现问题
3. 牢固性(Immobility): 设计难以重用
   设计中包含了对其他系统有用的部分，但是把这部分从系统中分离出来代价和风险很大
4. 粘滞性( Viscosity):难以做正确的事情
   保持系统设计的改动方式比破坏设计的改动方式更难实现应用
   开发环境迟钝笨重导致开发人员不想编写需要大规模重编译的改动代码
5. 不必要的复杂性(Needless Complexity):过分设计
   为过多的可能性做了准备，致使多了很多不会用到的设计结构，让程序变得不好理解
6. 不必要的重复(Needless Repetition):滥用鼠标进行拷贝粘贴
   复制粘贴并小改动代码表示开发人员忽视了抽象
7. 晦涩性(Opacity): 混乱的表达
   模块难以理解，开发人员没有站在代码阅读者的角度，需要重构代码

软件腐化的原因：

1. 需求没有按照设计预见的方式进行变化
2. 改动急迫且违反了原来的设计

软件项目中需求是持续变化的，如果软件设计由于需求变化而退化，那我们就不是敏捷的。

敏捷团队不在一开始设计模块时就试着预测程序会怎么变化，不进行预先设计，用许多单元测试和验收测试辅助，使系统设计尽可能的干净简单，直到需求变化的时候才修改模块设计，使之对该种变化保持弹性，每次迭代结束生成的系统都只满足那次迭代中需求。

敏捷团队应该：

1. 遵循敏捷实践去发现问题
2. 应用设计原则去诊断问题
3. 应用适当的设计模式去解决问题

面向对象设计原则:

1. 单一职责原则( The Single Responsibilty Principle,简称SRP)
2. 开放–封闭原则(The Open-Close Principle,简称OCP )
3. Liskov替换原则(The Liskov Substitution Principle,简称LSP)
4. 依赖倒置原则(The Dependency Inversion Principle,简称DP)
5. 接口隔离原则(The Interface Segregation Interface,简称ISP )

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

定义

1. 职责就是“变化的原因”，对于一个类，如果你能想到多于一个的修改的动机，那这个类就具有多个职责。
2. 我们习惯用面向对象的思维先创建类，然后基于这个类可能具有的一组行为去考虑这个类的职责。
3. 每一个职责都可以看成一根轴线，需求变化会反映到这个轴线上，如果有多个职责就有多根轴线，那引起类变化的原因就有可能有多个，一个职责的变化可能会抑制该类完成其他职责的能力。

原则

1. 常常会有一些原因迫使我们把不愿耦合在一起的东西耦合在一起。
2. 对于没有遵守SRP的类，只有在需求发生变化并导致职责轴线受到影响的时候再去对该类执行职责分离
3. 如果需求的变化总是导致两个职责同时变化就没有必要去分离，这时候分离反而会提高复杂性。
4. 测试驱动的开发模式常常会使我们很早就将职责分离，如果测试不能迫使我们分离职责的时候，就应该用FACADE或PROXY模式对职责进行重构。

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

定义

主要特征：

1. 对于扩展是开放的
   模块的功能可以根据需求变化扩展。
2. 对于更改是封闭的
   扩展模块功能时，不改动源代码和二进制文件。

原则

• 对模块的基础操作依赖于一个固定的抽象体，所以可以做到不更改模块基础操作的同时从这个抽象体派生来扩展模块的行为。
• 如果预测到变化就可以设计一种抽象来隔离它，但无论模块多么“封闭”，都会存在一些无法对之封闭的变化，要有策略地选择应对哪种变化。
• 由于遵循OCP要花很多时间精力去创建正确的抽象，所以在有限的成本下，把OCP尽可能应用在可能发生的变化，并且直到发生变化时才采取行动。
• 在我们认为可能发生变化的地方放置吊钩并维护它。
• 只承担一次变化造成的改动代价，但不允许下一次被同类型的变化带进去，以要让变化来的越早越好，于是就要去刺激变化：
  1. 测试驱动
  2. 短迭代周期
  3. 在加入基础结构时就开发特性并展示给使用者
  4. 优先开发最重要的特性
  5. 早发布