架构启示录

背景

2017年6月3日，本人参加了一个培训机构组织的架构分享大会，大会的主题是“一言以蔽之，十年架构之路汇成一句话”，八位一线专家现场畅谈对软件架构的理解和体会，剖析和分享架构实践过程中的难忘的问题。我这种井底之蛙，听完之后果犹如醐醍灌顶，眼界大开。
同行同事归程途中感慨以前工作都荒废了，需要学习补课了。我也是这样想的啊，说来也挺巧，最近也是开始反思个人能力水平，开始关注软件架构，正好单位提供了这次学习的机会。现场各位前辈们的分享，在这里规整一下，作为二次分享，也是一个学习消化的过程。

架构与复杂度的关联

以一张复杂系统管理的图片，从结构的可解能力和系统行为的可预能力两个纬度来衡量系统的结构。百度下来这张图，结合当时听到的解说，其实是可以理解这张图的。
复杂系统管理：1.一个系统的“结构”可能是”Simple”,”Complicated”; 2.一个系统的“行为”可能是”Ordered”, “Complex”, “Chaotic”; 3.放在一起变成Matrix, 架构师可以试着”Simplify”或者”Linearize”一个系统。

大规模软件的问题

软件规模，跟城市规模类似，也分为大城小镇，城市规模越大，就可能面临交通拥堵问题，比如帝都。
软件开发过程中的造成拥堵的原因分析：
耦合调用
需求变更
热点代码的修改更迭过程
这也是系统结构从干净整洁演变到混乱的过程，即“熵”的变化。物理学上，“熵”用来表述事物的混乱程度。
技术债：遗留系统的维护费用超过它产生的新价值的时候，就会产生技术债。区别于工程中的不良代码，它是程序员采用的一种主动性、策略性的方案。债务不是偶然发生的，它是人们在特定的情况下，为了能够立即获得某些东西，采取暂时性亏欠并承诺未来连本带息一起偿还的一种行为。

软件系统的知识载体

毋庸置疑，软件系统的三个知识载体，在国内软件开发行业或多或少都是不靠谱的，这点我深有体会。
代码，从自己任职的三家单位来看，只有第一家单位的规范体系以及执行比较严格，它由于是金融软件，介于行方的压力，代码审查、编码规范等监控比较到位。随后两家单位几乎没有开发相关的规范，尤其是现在任职的公司，虽然公司已经通过了CMMI5认证，但是我所在的部门情况看，连CMMI2都达不到。
我个人还是得益于第一家单位的工作经历，至今仍然保留着对代码干净整洁的规范意识。
文档，问题归根是配置管理的工作。
团队，团队成员所掌握的知识，可能会随着人员的流动、离职而淹没。所以团建、分享与交流，对维护软件知识大有裨益。

康威定律

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. – Melvin Conway(1967)
即：系统设计过程，模块的分解应该与组织结构保持一致。

DDD领域驱动开发REST方式定义服务。百度了一下，有讲康威定律和微服务的文章。链接参考：https://yq.aliyun.com/articles/8611

C4架构层次

无序设计的解决之道，就是“整洁架构”，整洁架构的原则就是保持架构的清晰和一致性。
四层框架：

4C架构层次，第一层是系统的上下文环境，即与外部系统之间的交互环境；第二层是容器，具有高度的自治能力；第三层是各个组件，最后一层是具体的类。
个人理解，这四层，是对系统结构的逐步细分。

整洁代码之道

此处讲师分享的一个实际案例是：他们曾经重构过一个系统，一个30万行代码的模块中的DAO有三种形式（ORM、Util、JDBC）。
我以为这其实已经不是架构的问题，而是编码约束、风格一致性的问题。这在现实开发过程中很常见，如果没有统一的约束，每个开发者都是按照自己的喜好来编码，当然会出现N中种同的DAO代码了。
代码层面上保持软件系统的整洁特性，有一些方法可以实践的，它们也是切实可行的：

启示录

井底之蛙如我，目前为止没有机会接触到高大上的技术东西，编码水平上已经达到瓶颈，感觉编码已经没有什么技术含量了，迫切需要寻求新的提升方向，虽然目前还没机会接触架构层面的工作，了解、关注一下，也能开阔不少视野。
周末借了一本张亚勤先生的传记，看完之后更觉得自己有必要学习进步了。

来源：毕小宝