这几个月我正在阅读的是编程之美系列书籍，《架构之美》是我看的第一部。全书只有前面两个部分吸引了我，后面的基本上是食之无味地略过。后来想想，此书成书于2009年，有些思想以及对编程的认识，在那个时候可能还是特别有吸引力的，但是拿到现在，可能并没有那么大的吸引力，一是因为这本书的后面部分讲得并不深入，另一个原因是新时代的语言满天飞，老式的语言对于我这种半吊子来说毫无兴趣。
书的前面部分主要讲了一些架构的基本概念和原则。比如，美丽的架构所展示的一些普遍的原则:
- 一处一个事实：重复导致错误，所以应该避免
- 自动传播：由一些构建工具支持
- 架构包含构建：架构不仅包含运行时系统，而且必须包含它的构建方式
- 最少量机制：实现某个功能的最佳方式要视情况而定，但是美丽的架构不会追求“最佳”。
- 构建引擎
- 增长的阶
- 抵制熵增
以及相应的更完整的解释:
- 功能性(Functionality)：产品向他的用户提供哪些功能
- 可变性(Changeability)：软件将来可能需要哪些改变？哪些改变不太可能发生，不需要特别容易进行这些改变？
- 性能(Performance)：产品将达到什么性能？
- 容量(Capacity)：多少用户将并发使用该系统？该系统将为用户保存多少数据？
- 生态系统(Ecosystem): 该系统将与其他系统进行哪些交互
- 模块化(Modularity):
- 可构建行(Buildability): 如何将软件构建为一组组建，并能够独立实现和验证这些组件？哪些组件应该复用其他的产品，哪些应该从外部供应商处获得
- 产品化(Producibiity): 如果产品将以几种变体的形式存在，如何开发一个产品线，并利用这些变体的共性？产品线中的产品以怎样的步骤开发等
- 安全心(Security)
概念性的东西其实到处都有，但是在第一部分里面，即使是讲述概念方面，作者的表达方式也是非常让人有读下去的欲望的。于是顺着作者的思路就来到了一个伟大软件架构的诞生的历程，不过那几个软件奇葩的名字还真是让人费解。好在作者用了最有效最真实的方法来讲述一个软件架构如何做到完美的。要想往完美的架构迈进，首先要做的就是承认，世界上没有完美的架构，只有在不断演化中，不断适应需求中，架构才能越来越完美。其实架构本身就已经很美了，每次我看到同事画的或是自己画的架构图，都觉得真美呀，特别是当自己画的架构图能够一下子让大家都看懂的时候。正如我在实际工作中所体验的一样，本书也认为架构的输出图是最重要的，有了图，我们的工程师才知道该做什么，才知道为什么要那样做。由于保密的问题，我肯定不会把公司内部的架构图放在这里，但是相信我，我们工程师画的每一张架构图，都是特别美的。
以前的我会认为编程是一件十分简单的事情，因为无论什么语言，只需要花两三天看一下基本的语法就能用那种语言写一个东西出来，但是在实际的工作中，我才明白，编程最重要的绝对不是编程语言，编程语言反而是最次要的，最重要的是如何根据当前的需求以及未来可能出现的需求而设计出的“最完美的架构”。
语录:
软件的架构其实是和公司的组织结构及开发流程相互影响的。当然大多数情况下是软件的架构是被动者。但好的软件架构设计原则反作用于组织机构及开发流程也不是不可能的。
没有完美的架构。架构师就是力求做一个务实的“平衡美人”。不能一边坐拥着间接、长远才见效、容易视而不见的幕后优点，一边又对为了实现前者随之带来的小小应付成本挑三拣四，这样很容易捡了芝麻丢了瓜。。。
好的架构就是要分离关注点，也即“庖丁解牛，分而治之”。降低耦合性，这样复杂性也随着降低了，让参与系统各个方面的开发测试人员只需了解自己需要了解的模块，不需要了解整个系统，就能并行地进行工作了。只有这样才能开发出超越了单个人智慧所能理解的复杂软件生态系统平台。对于复杂系统的大部分参与人员：“知其然，也要知所以然”未必适用。
构架在最初构想的时候，可以脱离实际，思考出解决问题的最佳途径，但是在实施过程中，必须要考虑细节。
架构是一个过程，而非一个结果。
但是，你仍然可以不必过多担心功能就开始设计架构。你关注的是需要满足的品质。
Fred Brooks说，概念完整性是架构最重要的特征：“最好是让系统反映一组设计思想，而不是让系统包含许多好的思想，而这些思想却彼此独立而不协调”（1995）
注意：软件架构不是一成不变的。需要时就改变它。要想做到可以修改，架构就必须保持简单
像一座建筑或一个城市的物理架构一样，系统的架构必须适应环境，利用该架构创建的工件将存在于该环境之中。
在每一种情况下，我们都会先探索所有可能性，然后再做决定。我们会在“最后可能的时刻”做出决定，即不做决定的代价超过了实现该特征的代价。尽管如果一开始就用Spring，有些事情我们可能会做得不一样，但在后来加入它也没有让我们受苦。在早期的迭代中，我们关注的是发现应用想成为什么样子，而不是Spring希望我们如何构建应用。
如果，在采取了所有让任务能够由单人处理的方法之后，架构任务仍然巨大而复杂，不能由一人来完成，那么产品肯定是太复杂了，以致不实用且不应构建。换言之，单个用户必须能够理解计算机的架构。如果计划的架构不能由一个人设计，那它也不能被一个人理解。（1997）
例如，如果我们请你来设计一个“基于Web的应用”，你首先问我们页面布局和导航树，还是问下面这些问题： ·谁提供应用主机托管？托管的环境有什么技术限制吗？ ·你想运行在Windows服务器上还是在LAMP栈上？ ·你想支持多少并发用户？ ·应用需要怎样的安全性？有需要保护的数据吗？应用将运行在公网上还是在私有的内部网上？ ·你能为这些答案排列优先级吗？例如，用户数是否比响应时间更重要？
软件架构师的首要关注点不是系统的功能。
架构的最主要产出是什么？我的答案是：图。这里面有两层含义：一层含义是如同建筑师描绘的蓝图一样，用于引导实施者；另一层含义是架构师头脑中清晰的目标系统。如果架构师头脑中没有系统清晰的图像，他是没有办法把它画出来的。
