《架构之美》阅读笔记一

软件架构的设计受到许多因素的制约，架构是好是坏并没有统一的标准。这取决于人们对软件的需求、软件被构建和运行的环境，以及软件团队本身的特点等等因素。评价软件好坏有很多指标，例如性能、安全、可伸展性等等。一般来说，这些指标是很难全部满足的，试图改进其中一个往往会对其他指标产生负面影响。所以从某种意义上来说，软件架构是折中的游戏。对于一组功能需求和品质需求，没有唯一的正确架构。

《架构之美》没有太多空洞的概念和论述，而是抛砖引玉地展示多个实际的项目。通过对它们架构利弊的分析，以及相关的思考，给读者提供了有益的启发

书中提到了很多有关一个优秀的架构师应该具备的品质很吸引我的眼球，好的架构师首先关注的并不是系统的功能而是系统需要满足的品质，它指明了功能以何种方式交付才能被系统的利益相关者普遍接受，系统的结果包含了这些stakeholders的既定利益。成功的架构师的两项重要实践是：让利益相关者参与和同时关注系统的功能的品质和功能。

书中介绍了什么样的的架构才算是美丽的架构，美丽的架构在开始时，要关注其实用性，好的架构应该是每天被很多人使用的；使用架构之前，我们还要考虑它必须要能够被构建（可构建性）；接下来就是关注架构的可持久性，好的架构应该能够经得起时间的考验，能够考虑到未来的变更，允许期望的修改；最后，要寻找一些能让人高兴的架构（开发人员、测试人员、用户等），这就要求架构必须满足概念完整性，这样的架构才易懂，易用，才会做到简单而又不过于简单。几个比较常见的美丽架构的例子有：A-7E舰载飞行处理器的架构；朗讯5ESS电话交换机软件架构；万维网；UNIX系统。

在后来的章节中，又介绍了“混乱大都市”和“设计之城”两个项目，将两种比较，形象的说出了好的架构与差的架构的一些特性。“混乱大都市”的最大问题是重复，它没有考虑好软件设计中最关键的品质，内聚和耦合。它的失败经验很值得我们借鉴：缺乏预见性和对架构的整体思考。版本的发布周期过于漫长；系统没有弹性，可扩展性差；代码问题很严重，没有统一的命名规则和命名结构，导致新员工面对复杂的代码结构，感觉压力比较大，从而又造成了员工的跳槽和士气低等问题；团队的内部政治问题严重，没有团结精神，缺少凝聚力。