编程与架构：由相同底层规则连接的宏观与微观

不少程序员认为编程和架构是两个独立的知识领域，或者是逐级递进的关系，这两种理解都不准确。用推导[[架构知识模型的推导：信息交换+架构编排+架构演进|架构知识模型]]同样的方式去看编程，能得到一个结构完全平行的”编程知识框架=信息交换+代码编排+代码演进”：信息交换方面，架构关注系统维度的需求，编程关注模块维度的需求；编排方面，架构关注把子系统或微服务有序组织起来实现业务功能，代码编排关注把模块或类有序组织起来实现技术功能或局部业务功能；演进方面，架构演进和代码演进的源头都是业务需求变更，只是架构演进关注整体层面、代码演进关注代码层面。这说明架构更关注宏观、编程更关注微观，但两者用的是同一套结构、同一套规则——编程里的高内聚低耦合，在架构里同样适用。更进一步，有些表面上不相关的规则，其实共享同一条底层规则：代码开发里的MVC模式和架构里的应用分层，本质上都是”还原论”思想的应用（把复杂整体拆解成职责单一的部分）；代码开发里的异步响应请求和架构里的CAP原理，本质上都是”升维模式”的应用（引入一个新的维度——时间异步性或分布式一致性的取舍——来化解原本无解的矛盾）。这意味着编程和架构之间存在一座双向互通的桥梁：程序员可以借助已有的编程经验更快掌握架构知识，架构师也能反过来加深对编程本身的理解，二者可以形成螺旋上升的关系——优秀的架构师大概率也是优秀的程序员，反之亦然，二者更像是宏观包含微观、微观处处映射宏观样貌的关系，而非彼此隔绝或单向递进的关系。

结构图：

flowchart TB
  P["编程知识框架=信息交换+代码编排+代码演进<br/>(微观:模块/类/代码层面)"]
  A["架构知识模型=信息交换+架构编排+架构演进<br/>(宏观:系统/子系统/整体层面)"]
  P <-.相同结构,相同规则(如高内聚低耦合).-> A
  M["MVC(代码)"] -.同属还原论.-> D["应用分层(架构)"]
  R["异步响应请求(代码)"] -.同属升维模式.-> C["CAP原理(架构)"]