读《演进式架构》有感

麒思妙想

发布于 2020-07-10 10:35:30

5160

发布于 2020-07-10 10:35:30

文章被收录于专栏：麒思妙想

最近读了一本很有意思的书《演进式架构》，从一个不太一样的角度来描述架构这件事。也让我痛定思痛的反省了一下过去犯的错误，以及由于知识欠缺，所留下的遗憾。

这不是一篇介绍书目的软文，所以不会通篇介绍书中内容，我也没有电子版的链接，单纯是结合个人经历抒发一些感慨......

Evolutionary Architecture

它的定义原文如下：

An evolutionary architecture supports incremental, guided change as a first principle across multiple dimensions.

翻译过来大致是演进式架构是一种支持将增量式、指导式的变更作为跨多个维度中的第一原则的架构。

这里涉及到几个要素：

Incremental change
Guided change with fitness functions
Appropriate coupling

独轮车理论

做架构，就像表演杂技独轮车，你要保持车身的平衡，同时还要接住一个个球，并且让他们也加入这个平衡里来。

一个个球，就是人力资源、时间节点、功能需求、性能需求等等，在不摔下来的前提下，你不能接住所有的球，那么如何选择你的策略，就是亟待解决的问题，在时间节点固定的前提下是加大人力投入？还是砍需求？或是，客户要求的功能一定要实现的前提下，去游说到更多的时间和人力资源...

长袖善舞...也是架构师必要的技能

康威定律

Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967) 设计系统的组织其产生的设计等价于组织间的沟通结构。

反向理解起来也是成立的。

Conway’s law reversed：You won’t be able to successfully establish an efficient organizational structure that is not supported by your system architecture design. 如果系统架构不支持，你无法建立一个高效的组织。

对于这一点，我的体会更深一点，在做BI产品的时候，起初我们将产品分成了若干功能模块，然后按照模块来构建团队，起初还是很顺利的各个模块表现良好，每一个模块其实都可以作为一款单独的产品来卖了。但是攒成一个BI产品，整体上，总是欠缺一点东西，融合不到一起的感觉，这也是困扰V3-V5的一个通病了。现在回想起来，当初一直要推行杜绝“各扫门前雪”的行为，也真的挺无奈的，是不是当时做一些组织结构的调整能好一些呢？

增量变更

Incremental change describes two aspects of software architecture: how teams build software incrementally and how they deploy it.

其中增量构建，比如向前兼容，多版本支持；部署的话，比如蓝绿部署、金丝雀部署、feature toggles等。

它要求这些变更是可逆的，即可以回滚。当然有些架构是用来抛弃/牺牲的。比如可牺牲的架构中提到的：

支持1996年eBay的合适架构，对于2006年eBay来说，就不是合适的了。1996年的架构无法处理2006年的负载，但是2006年的版本太过复杂而难以建立、维护，它是根据1996年的需求演化而来的。的确，这个原则可以引出工作的一种组织方式。在Google，大家熟知的要求就是设计一个满足当前10倍需求的系统，这暗示着如果需求超过了一个数量级，那么扔掉并从头做起是更好的。每隔几年就被重新设计与抛弃的子系统而言，这是非常普遍的。

适应度函数

这个是书中最晦涩的部分，我特意查了下原文，“fitness functions”翻译上似乎没有什么问题，但是总觉得怪怪的。