架构之美(二) （摘要）

第二章：两个系统的故事

2.1 混乱大都市

总结出的特征

1. 代码需要花极长的时间学习，没有显而易见的进入系统的路径。

2. 从每个程序，每个方法，每个组件来看，代码都是混乱而粗糙的叠在一起。不存在一致性，不存在风格，也没有统一的概念能够将不同的部分组织在一起。

3. 系统中的控制流让人觉得很不舒服，无法预测

4. 数据很少放在使用它的地方，经常引入额外的巴罗克式缓存层，目的是试图让数据停留在更方便的地方。（注：巴罗克一词原指不规则的，怪异的珍珠）

5. 不好的公司结构和不健康的开发过程将在糟糕的软件架构中得到体现。

6. 糟糕架构的后果：

a) 不可理解：注意，重要的是保持软件设计的品质。坏的架构设计会招致更坏的架构设计（坏的设计确实会招致在他上面叠加坏的设计）

b) 缺乏内聚：系统组件完全没有内聚。每个组件本来应该有一个定义好的角色，但他们却包含了一堆杂乱的，不一定相关的功能，这使我们很难确定组件存在的原因，也很难弄明白系统中已实现了哪些具体功能。功能和数据放在系统中错误的地方，“核心服务”没有在系统核心部分实现。

c) 不必要的耦合：模块之间的依赖关系不是单向的，耦合常常是双向的。组件A会到达组件B的内部完成一项任务。其他地方，组件B又通过硬编码调用了组件A。单个组件的任何改变都会波及其他组件。代码层次的测试不能进行，组件层次的集成测试也不能创建。

d) 代码问题：没有命名规范；重复：通用算法和数据结构在代码集中不断重复出现，很多实现都带有一些未知的缺陷和怪异的行为特征；更大范围的关注点，如外部通讯和数据缓存也实现了很多次。

e) 代码以外的问题：架构的腐烂影响到了支持和使用它的人：

i. 开发团队：项目复杂性导致流失率提高；项目压力大；规划新功能导致极大的恐惧。

ii. 缓慢的开发周期：难以维护，管理软件开发周期非常困难，管理层对开发团队不能满足业务目标失望

iii. 支持工程师：需要了解很小的软件版本差异之间错综复杂的行为差异

iv. 第三方支持：外部支持协议也反映出此架构，第三方工程师难以理解

v. 公司内部政治：开发与营销团队关系紧张。

7. 清晰的需求：混乱的重要原因是：项目开始之初，团队不知道要构建什么。开始设计架构之前，需要知道你打算设计什么。只设计你知道需要的东西。

8. 缺少预见性和架构设计，将导致一下问题；

a) 低品质的代码和漫长的软件版本发布周期。

b) 系统没有弹性，不能适应变更或添加新的功能。

c) 无处不在的代码问题。

d) 员工问题（压力大，士气低，跳槽等）

e) 大量混乱的公司内部政治。

f) 公司不能成功。

g) 许多痛苦和面对代码深夜加班。

2.2 设计之城

1. 第一步，确定主要的功能领域。

2. 系统中各独立部分的相对位置关系体现为传统的分层结构。

3. 早期选择了项目将采用的支持库。

4. 决定一些基本关注点，使代码能够容易且一致的增长，包括：

a) 顶层文件结构

b) 如何对事物命名

c) “内部”展示风格

d) 共用的的编码惯例

e) 选择单元测试框架

f) 支持基础设施（如版本控制，适合的构建系统和持续集成）

5. 按照XP（极限编程）过程推进，设计和编码要么以结对的方式完成，要么经过仔细的复审。

6. 良好架构产生的结果：

a) 定位功能：一开始就有系统清晰总体视图，新的单元可一致性的加到代码集的正确功能区域。新代码放到“正确位置”比简单放到方便的位置可能要更难，但回报是：维护或扩展系统时，不愉快的事情会减少。架构有助于定位功能：添加功能，修改功能或修复缺陷，他为你提供一个模板，让你将工作纳入到一张系统导航图中

b) 一致性：清晰的架构导致一致的系统。所有的决定都应该在架构设计的背景下做出。清晰的架构有助于减少功能重复.

c) 架构的增长:系统设计像代码一样,被认为是可扩展,可重构的。软件架构并非一成不变，要想做到可以修改，架构必须保持简单，牺牲简单性的修改要抵制。

d) 延迟设计决定：延迟设计决定，知道必须做出决定为止。不要在还不知道需求时就坐出架构决定。不要猜测。XP（极限编程）的一项原则：YAGNI:如果你不是马上需要，就不要去做。早期只设计重要的部分，剩余决定推迟。直到对实际需求有了更清晰的理解，并知道如何放在系统中最好时，再做出决定。

i. 当你还不理解问题是就开始设计，是一件糟糕的事。

ii. 创建软件设计时加入所有可能需要的东西是危险的：大部分设计将是无用功，得到的只是额外负担，需要在整个生命周期支持这些设计。，一开始就增加成本。

e) 保持品质：准备一些品质控制过程：1.结对编程，2.对没有结对编程的工作进行代码/设计复审。3.对每一段代码进行单元测试。必须保持架构品质，开发者相信它并对他负责时，才能做到。

f) 管理技术债务：注重开发时效，最后期限临近，不太重要功能砍掉，使产品准时推出。小的代码“瑕疵”或设计问题允许存在于代码集中：为了让功能尽快实现或在接近发布时避免高风险改动。这些问题被标记为技术债务，安排在后续版本修复。

g) 单元测试打造了设计:

i. 所有代码都要单元测试，（XP极限编程开发强制要求的）。单元测试带了很多好处，其中一项就是：能够修改软件的一些部分，而不必担心在修改的过程中破坏其他的东西。系统应该有一组不错的自动化测试，使得在进行架构变更时风险最小。

ii. 单元测试的另一个好处：很大程度上定型了系统设计：迫使我们实现更好的设计。编写单元测试确保了每个模块的内聚性，也确保系统其他部分之间的松耦合。对你的代码进行单元测试将带来更好的软件设计，所以设计时要考虑可测试性。

h) 设计时间：好的项目计划带来优质的设计。分配足够的时间来创建架构杰作，它们不会立即出现。

i) 与设计同行：团队的组织方式必然对他产生的代码有影响，随着时间推移，架构也会影响团队协作的好坏。Conway法则：代码结构符合团队结构：如果让四个小组开发一个编译器，会得到一个四阶段编译器。

7. 好的架构是很多因素的结果：

a) 确实进行有意为之的前端设计

b) 设计者的素质和经验

c) 在开发过程中，保持清晰的设计观点

d) 授权团队负责软件的整体设计，而团队也承担起这一责任

e) 不要害怕改变设计，没有什么是一成不变的

f) 让合适的人加入到团队中，包括设计者，程序员，经理，确保开发团队的规模合适。确保它们之间健康的工作关系。

g) 在合适的时候做出决定，当知道所有必要信息时再做出决定。延迟暂时不能做出的决定。

h) 好的项目管理，适合的最后期限