《架构之美》阅读笔记02

　　首先我看了关于混乱大都市这一节，了解了微观层面特点没有统一的概念将不同的部分组织起， 代码风格不一致控制流无法预测，即控制流的流向很复杂，额外的数据缓存，其目的让数据停留在更方便的地方（但是，容易造成数据的不一致性，维护或扩展不方便），没有人了解整个系统，没有任何文档，宏观层面特点，系统没有弹性，无法变更和添加新功能版本周期过长，低品质的软件对第三方支持协议，涉及太多内部结构。会出现难以理解的、不容易复现的错误。团队新成员不理解整个系统，不能搞请状况，流失率高。而造成的恶果的原因：没有清晰的需求。这个是项目开始之初，团队就不知道要构建什么。这个是混乱的一个重要原因，系统结构难以理解，坏的架构设计只会招致更坏的设计（因为想解决问题，只能选用阻力最小的方法）缺乏内聚，不相关的功能放在一起，没有清晰的角色定义不必要的耦合。系统没有最底层，没有控制中心，所有组件必须一开始就创建。这使得代码层次的测试不能进行。没有共同的代码风格，没有共同的库，没有共同的命名习惯。重复的代码到处被使用，开发周期过长，造成整个系统测试、迭代困难，软件质量没有保证,这个即使恶果，又是原因之一。而比较成功的设计，往往是一个持续的过程，不仅仅表现为几个特征，如设计之城的各阶段的特征：

在设计早期：

1. 确定了主要的功能领域，并推出初步架构

2. 系统中各独立部分的位置关系体现为传统的分层结构。并且，这些是基本的系统设计，可以随功能模块添加进行扩展。

3. 一些基本关注点的决定：
1） 顶层文件结构
2） 如何对事物命名
3） 内部"展示"风格
4） 共同的编码惯例
5） 选择单元测试
6） 一些基础设施的选择（如版本控制、系统的构建与持续集成）

第二阶段，功能扩展：

1. 新代码的定位
一开始就有系统结构清晰的总体视图，所以，新的功能单元可以添加到正确的功能区域，而不是为了一时方便，代码随意添加。（这样，有的时候开发者的工作会需要动写脑筋，但是在系统维护和扩展时，就变得容易了）

2. 系统的一致性
顶层设计的良好风格和决定，为底层代理好处，代码是统一、整洁的。清晰的定义，确保没有重复的代码、接口惯例和常见设计模式被普遍使用、没有特殊生命周期的对象和资源管理问题。（这个重点是在于减少功能重复）

3. 架构增长
没有什么是一层不变的，架构应该是方便扩展、可重构的。这样，代码可以快速增长，同时又保持好的内部结构，添加新的功能不是问题。

4. 延迟设计决定
这部分应该是需求问题。YAGNI（如果不是马上需要，就不要去做），早期只设计中要的部分，将余下的决定推迟。特别是，不确定的需求，需要猜测。

5. 保持品质
结对编程、对代码复审、单元测试。对不正确、不合适的变更都要拒绝。开发者需要对设计负责。

6. 技术债务管理
什么是技术债务？为了赶时间，对于不太重要的功能被砍掉，允许小的代码"瑕疵"存在，发布时避免高风险的改动。这些都应该被标记为技术债务。
应该选择合适的时间，及时集中清理这些技术债务，在后续版本中修改。

7. 单元测试 打造设计
单元测试在很大程度上定性了代码设计，它迫使我们实现好的结构，保证可测性。

8. 遵守设计
新的成员可以比较容易地拿起代码开始工作。开发团队动态地遵守架构设计，项目原则规定没有人"拥有"某部分设计，而是所有人都应该写出高品质的代码，可以改动系统的所有地方。

未来：

1. 没什么是一成不变的，在整洁的背景下，突出的技术争论应该被解决掉。着重于适应性强的架构和灵活的代码结构。