第二部分敏捷设计

敏捷团队不会花费许多时间去预测未来的需求和需要，也不会试图在今天就构建一些基础结构去支撑那些他们认为明天才会需要的特性。

第 7 章什么是敏捷设计

软件系统的源代码是它的主要设计文档，用来秒回源代码的图示只是设计的附属物而不是设计本身。

设计的臭味：

僵化性（Rigidity）：很难对系统改动，一个改动需要其他部分一起改动。
脆弱性（Frgility）：系统的改动会导致其他概念无关的地方出现问题。
牢固性（Immobility）：很难解开系统，抽取出重用组件。
粘滞性（Viscosity）：做正确的事情比做错误的事情更难。（实现或变更一个需求时，生硬的方法很简单，保持系统设计的方法很难；或开发环境迟钝低效时，开发人员会倾向于做不会导致大规模重编译的改动，即使那些改动不再保持设计）
不必要的复杂性（Needless Complexity）：设计中包含不具有任何直接好处的基础结构。
不必要的重复（Needless Repetition）：设计中包含重复结构，而该重复结构本应使用单一抽象进行统一。
晦涩性（Opacity）：很难阅读，理解。没有很好的表现出意图。

设计的退化是因为需求没有设计遇见的方式进行变化。改动很急迫，且改动人员对原始设计并不熟悉。

在要实现新需求时，团队抓住这次机会去改进设计，以便设计对于将来的同类变化具有弹性，而不是设法去给设计打补丁。

在不知道某个需求是否会变化的时候，现在就添加额外的保护没有任何现实意义。如果需要这种保护时，应能非常容易的添加。

不能接受代码腐化。

就一个类而言，应该仅有一个引起它变化的原因。如果一个雷承担的职责过多，一个职责的变化可能会削弱或职责和抑制这个类完成其他职责的能力，从而导致脆弱的设计。当变化发生时，设计会遭受到意想不到的破坏。

职责：变化的原因（a reason for change）。

仅当变化实际发生时考虑 SRP 或任何其他原则才具有意义，如果没有征兆就考虑是不明智的。

OCP 对于扩展是开放的，对于更改是封闭的。

一般而言，无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。没有对于所有的情况都贴切的模型。

遵循 OCP 的代价是昂贵的，创建正确的抽象是要花费开发时间和经理的，同时也增加了复杂性。开发人员有能力处理的抽象的数量也是有限的。OCP 的应用应限定在可能会发生的变化上。所以我们应该进行适当的调查，提出正确的问题，并且使用我们的经验和一般常识。最终，我们会一直等到变化发生时才采取行动。

通常，我们更愿意一直等到确实需要哪些抽象时再把他放置进去。

使用数据驱动的方式获取封闭性。

版权所有，转载请注明出处：
https://sickworm.com/?p=1687