架构之美--第2章 两个系统的故事：现代软件神话

这一章节，作者拿他曾经参与过的两个项目对比好架构与坏架构的表现和影响，经验之谈

坏设计的一些表现：

1，不可理解 ： 重要的是要保持软件设计的品质。坏的架构设计会招致更坏的架构设计

2，缺乏内聚 ： 开发团队中健康的工作关系将直接有益于软件设计。不健康的关系和个性膨胀会导致不健康的软件。内聚性是将模块粘成一个整体的胶水。弱内聚的模块是不良分解的信号。每个模块都必须具有清晰定义的角色，而不只是一堆不相关的功能。

3，不必要的耦合 ： 紧耦合将导致不可测试的代码

4，代码重复问题 ： 松弛而模糊的架构将导致每个代码组件编写得不好，而且相互之间匹配得不好。它也会导致重复的代码和工作。

5，代码以外的问题 ： 不良架构的影响不仅限于代码。它会进一步影响到人，团队，过程和时间表

好设计的一些表现：

1，在开始设计系统之前知道你打算设计什么。如果你不知道它是什么，也不知道它将做什么，暂时不要开始设计它。只设计你知道需要的东西。

2，较早的确定主要的功能领域，推出初步的架构，包括了实现性能需求所必需的核心线程模型。在系统核心上花了额外的设计时间。

3，早期确定了一些基本关注点，目的是确保代码能够容易而一致地增长，包括：a，顶层文件结构；b，如何对事物命名；c，内部展示的风格；d，共用的编码惯例；e，选择单元测试框架；f，支持基础设施（例如版本控制，适合的构建系统和持续集成）

4，定位功能 ： 架构有助于定位功能：添加功能、修改功能或修复缺陷

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

6，架构的增长：开发团队的一项核心原则就是保持敏捷，没有什么是一成不变的，所以在需要时架构也可以修改。要做到可以修改，架构就必须保持简单。牺牲简单性的修改要抵制。

7，延迟设计决定，直到我们对实际的需求有了更清晰的理解并知道如何放到系统中最好时，再做出这些决定

8，保持品质：开发者们相信设计，认为设计对项目相当重要。他们拥有设计，对设计负责

9，管理技术债务。随着项目期限的临近，一些不太重要的功能被砍掉，并标记为技术债务，安排在后续版本中

10，单元测试打造了设计：单元测试的好处之一是能够修改软件的一些部分，而不必担心在修改的过程中破坏其他的东西。另外可在很大程度上定型了代码设计，编写单元测试确保了每个代码模块的内聚性，也确保了与系统其他部分之间的松耦合。设计时要考虑可测试性。

11，有利的项目环境，合适的设计时间