演进式架构

二零二零年读完的第二十本书，今年读书的进度不是一点点慢，半年过去了才完成五分之一，我都开始怀疑能否完成既定目标了，跟 Martin 的《微服务设计》搭配着读更能理解其中的缘由。这本书不管是作者还是译者的写作功力都非常厉害，结构清晰，表述到位，不留废话。

- 整合方法论的书, 通常指适合决策群体, 受众有限, 而且离落地很有距离, 对大部分开发而言, 「show me the code」才是金科玉律

概念太多，不接地气；着重强调适应度函数，但对于怎么定义适应度，在各类业务场景下具体如何实操没有给出案例和说明。粗略看完后，云里雾里，不甚理解。

指引式，概念式小册子，提供架构演进指引，感觉叫进化会好一些，架构师就是体系的上帝。

主要收获： 1、围绕架构的各项特征维度创建适应度函数，并构建自动测试和自动验证。以防止架构腐化。 2、如何构建演进式架构。

看看还是可以学习到一些不错的理念。 例如从进化角度定义的适应度函数。 康威定律对业务、技术、团队的解释。 架构是对业务的抽象、提取关注点、隔离复杂度、从多个维度观看架构。 架构量子以物理学概念类比软件的基础构建单元，但是概念类比的时候阐述概念过少、带着这一块解释说明比较空洞不全面。 总的来说：看一看还是可以获取一些新的概念和视角。也能引发关于架构多角度的思考。 作者书里面试图从进化论、量子物理等概念体系来类比解释软件姿态的构成和演化。思路不出，但是概念引入的时候做充分的说明和定义还是比较有价值。毕竟、对非物理专业、甚至专业物理学生对量子理解都各不相同。

提出了一个适应度函数说法，说明适应度围绕着架构而走，并且做演进。 但是这种形式，看起来更像是一种变体的测试驱动开发。你可以认为所有的适应度函数是一种测试CASE。 并且，也没有对如何做演进架构做很好的说明。

主要以加入devops流水线的适应度函数建立起架构防腐和引导变更的栅栏。 作为架构师，一个难点是如何在架构首轮落地后仍持续保持着架构设计的执行、以及适时演进。常规手段是多做培训，拉齐团队对设计的理解；更多、全的代码走查。这些手段还是多依赖“人”去做，历史经验是随着人员出人、n次走查的覆盖不到位（时间？），几个月的逐步腐化就会导致专项重构或者重建（成本考虑有时重建会更合适）。 将架构设计约束点、特征（包括非功能性需求）建立适应度函数，以在代码入库前进行覆盖检查、监控，保障架构执行。这是架构层次的“单元测试”。

这本书的概念放在十年二十年前，也许值得一读。现在已经是基础理念了，长篇累牍啰嗦一大片，实际上就是一句话：软件架构需要根据实际需要来判定是否演进，演进需要适应性函数作指导。

架构上干货不多，新东西不多。围绕着适应度函数，如何演进讲了一大通。 适应度函数如何设计并没有非常好的落地经验，看起来更多是一种思想或者一个构建监控指标，卡点体系。 如何演进，如果你在大厂上班基本能学的不多，蓝绿发布，向前兼容性，数据兼容等。涉及架构的部分不如去看ddd。 少部分除了架构技术相关的倒提高了一些姿势，比如康威定律，比如简历驱动架构，这些名词算是增长见识。