第二章现代软件神话通过两个例子来进行架构的说明。
一、混乱大都市
微观层面特点：
-
1. 没有统一的概念将不同的部分组织起来
-
2. 代码风格不一致
-
3. 控制流无法预测，即控制流的流向很复杂
-
4. 额外的数据缓存，其目的让数据停留在更方便的地方（但是，容易造成数据的不一致性，维护或扩展不方便）
-
5. 没有人了解整个系统，没有任何文档
宏观层面特点：
-
1. 系统没有弹性，无法变更和添加新功能
-
2. 版本周期过长，低品质的软件
-
3. 对第三方支持协议，涉及太多内部结构。会出现难以理解的、不容易复现的错误。
-
4. 团队新成员不理解整个系统，不能搞请状况，流失率高
原因：
-
1. 没有清晰的需求。这个是项目开始之初，团队就不知道要构建什么。这个是混乱的一个重要原因。
-
2. 系统结构难以理解，坏的架构设计只会招致更坏的设计（因为想解决问题，只能选用阻力最小的方法）
-
3. 缺乏内聚，不相关的功能放在一起，没有清晰的角色定义
-
4. 不必要的耦合。系统没有最底层，没有控制中心，所有组件必须一开始就创建。这使得代码层次的测试不能进行。
-
5. 没有共同的代码风格，没有共同的库，没有共同的命名习惯。重复的代码到处被使用。
-
6. 开发周期过长，造成整个系统测试、迭代困难，软件质量没有保证,这个即使恶果，又是原因之一
二、设计之城
特点：
1、初期确定功能领域，确定架构;
2、系统设计采用分层结构，可随时进行添加扩展。
一个好的架构：
1、软件清晰的定义，分层的设计，功能划分明确，各部分的依赖关系，数据通信方式确定。
2、代码结构清晰，功能模块划分后，对于底层和组件的关系进一步分析，将结构进行分层设计。
3、外部接口与内部实现尽量分离。所有外部接口部分的声明都单独放在一个文件中，而内部结构的声明与实现放在其他文件中。
4、统一的框架和一些代码生成工具。保证了内部统一的风格，编码惯例。但是这些框架和工具也增加了入门的难度。
5、保证单元测试，并且有一个完整的simulator，离线模拟器，replay模块，保证了测试的及时性。
6、版本控制工具。其他比较大型的项目的通病： 编写比较复杂的结构，并使用一些自制工具，这使得入门比较难。知其然不知其所以然。
