接着读架构之美，对于这样的书真是不容易下心去读，尤其又是在这美好的寒假时光里。这次看了下第二章，感觉第二章依旧是引入阶段，也就是前戏，继续讲述架构。而且指向了有架构可寻的一些好处，我看出来也就是这样的了。
第二章大致是讲两个系统的比较，功能类似，但是结局不同。首先看混乱大都市， 没有统一的概念将不同的部分组织起来，代码风格不一致，控制流无法预测，即控制流的流向很复杂额外的数据缓存，其目的让数据停留在更方便的地方，没有人了解整个系统，没有任何文档。宏观层面特点：系统没有弹性，无法变更和添加新功能，版本周期过长，低品质的软件，对第三方支持协议，涉及太多内部结构。会出现难以理解的、不容易复现的错误。 团队新成员不理解整个系统，不能搞请状况，流失率高。造成的恶果的原因：没有清晰的需求。这个是项目开始之初，团队就不知道要构建什么。这个是混乱的一个重要原因。系统结构难以理解，坏的架构设计只会招致更坏的设计因为想解决问题，只能选用阻力最小的方法
缺乏内聚，不相关的功能放在一起，没有清晰的角色定义。不必要的耦合。系统没有最底层，没有控制中心，所有组件必须一开始就创建。这使得代码层次的测试不能进行。没有共同的代码风格，没有共同的库，没有共同的命名习惯。重复的代码到处被使用。开发周期过长，造成整个系统测试、迭代困难，软件质量没有保证,这个即使恶果，又是原因之一。
而对于设计之城来说，那自是有条有理，多阶段发展，虽然存在问题是不可避免的但是在逐个阶段的实施中却是没什么大的冲突的。这就是涉及到了架构的存在了，也就是是否有设计的存在了，对于设计来说就是对于我们前进的蓝图，万丈高楼平地起，没有蓝图胡乱建造必然会暴露出各种各样的问题了。