两个系统的比较，功能类似，但是结局不同。
这两个系统特点有什么不同？是什么导致了不同的结局？
混乱大都市
特点：
微观层面特点：
1. 没有统一的概念将不同的部分组织起来
2. 代码风格不一致
3. 控制流无法预测，即控制流的流向很复杂
4. 额外的数据缓存，其目的让数据停留在更方便的地方（但是，容易造成数据的不一致性，维护或扩展不方便）
5. 没有人了解整个系统，没有任何文档
宏观层面特点：
1. 系统没有弹性，无法变更和添加新功能
2. 版本周期过长，低品质的软件
3. 对第三方支持协议，涉及太多内部结构。会出现难以理解的、不容易复现的错误。
4. 团队新成员不理解整个系统，不能搞请状况，流失率高
原因：
造成的恶果的原因：
1. 没有清晰的需求。这个是项目开始之初，团队就不知道要构建什么。这个是混乱的一个重要原因。
2. 系统结构难以理解，坏的架构设计只会招致更坏的设计（因为想解决问题，只能选用阻力最小的方法）
3. 缺乏内聚，不相关的功能放在一起，没有清晰的角色定义
4. 不必要的耦合。系统没有最底层，没有控制中心，所有组件必须一开始就创建。这使得代码层次的测试不能进行。
5. 没有共同的代码风格，没有共同的库，没有共同的命名习惯。重复的代码到处被使用。
6. 开发周期过长，造成整个系统测试、迭代困难，软件质量没有保证,这个即使恶果，又是原因之一
------------
设计之城
而比较成功的设计，往往是一个持续的过程，不仅仅表现为几个特征
如设计之城的各阶段的特征：
在设计早期：
1. 确定了主要的功能领域，并推出初步架构
2. 系统中各独立部分的位置关系体现为传统的分层结构。并且，这些是基本的系统设计，可以随功能模块添加进行扩展。
3. 一些基本关注点的决定：
1） 顶层文件结构
2） 如何对事物命名
3） 内部"展示"风格
4） 共同的编码惯例
5） 选择单元测试
6） 一些基础设施的选择（如版本控制、系统的构建与持续集成）
在第二阶段，功能扩展：
1. 新代码的定位
一开始就有系统结构清晰的总体视图，所以，新的功能单元可以添加到正确的功能区域，而不是为了一时方便，代码随意添加。（这样，有的时候开发者的工作会需要动写脑筋，但是在系统维护和扩展时，就变得容易了）
2. 系统的一致性
顶层设计的良好风格和决定，为底层代理好处，代码是统一、整洁的。清晰的定义，确保没有重复的代码、接口惯例和常见设计模式被普遍使用、没有特殊生命周期的对象和资源管理问题。（这个重点是在于减少功能重复）
3. 架构增长
没有什么是一层不变的，架构应该是方便扩展、可重构的。这样，代码可以快速增长，同时又保持好的内部结构，添加新的功能不是问题。
4. 延迟设计决定
这部分应该是需求问题。YAGNI（如果不是马上需要，就不要去做），早期只设计中要的部分，将余下的决定推迟。特别是，不确定的需求，需要猜测。
5. 保持品质
结对编程、对代码复审、单元测试。对不正确、不合适的变更都要拒绝。开发者需要对设计负责。
6. 技术债务管理
什么是技术债务？为了赶时间，对于不太重要的功能被砍掉，允许小的代码"瑕疵"存在，发布时避免高风险的改动。这些都应该被标记为技术债务。
应该选择合适的时间，及时集中清理这些技术债务，在后续版本中修改。
7. 单元测试 打造设计
单元测试在很大程度上定性了代码设计，它迫使我们实现好的结构，保证可测性。
8. 遵守设计
新的成员可以比较容易地拿起代码开始工作。开发团队动态地遵守架构设计，项目原则规定没有人"拥有"某部分设计，而是所有人都应该写出高品质的代码，可以改动系统的所有地方。
未来：
1. 没什么是一成不变的，在整洁的背景下，突出的技术争论应该被解决掉。着重于适应性强的架构和灵活的代码结构。