01.《架构之美》阅读笔记

　　《架构之美》是Till Adam在2009年出版的一本书。这本书主要围绕一下5个主题领域来阐述架构之美：概述，系统、最终用户、应用和编程语言。本书让最优秀的设计师和架构师来描述他们选择的软件架构，剥开架构的各层，展示他们如何让软件做到实现功能、可靠、易用、高效率、可维护、可移植和优雅。

　　作者在书的开始之初就告诉我们什么是架构：架构是一组结构，来源于一组设计规则，他能够减少我们在设计中的复杂性。常见定义是，每种结构由各种类型的组件和关系组成，它们如何组合、相互调用、通信、同步、及其其他交互。我感觉，简单来讲，架构就是组件与组件之间的关系。而架构存在的目的就是确保利益相关人员的关注点能够得到满足，而在构想、计划、构建和维护系统时，系统架构能够处理复杂性。为了对付这种复杂性，系统被分解为一些交互的组件，而每种结构都有特定的关注点，如可变性和性能。各种关注点需要相互妥协、折中。而架构师的工作就是：

　　1）满足客户需要

　　2）整个系统应用相同的设计原则

　　3）满足法规和安全性需求

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