认知重构：对抗熵增最重要的一层，源头是人的熵减

软件系统对抗[[软件系统的熵增定律，及开放系统对抗熵增的机制|熵增]]的主要手段是重构，按对象类型可分四种：代码重构、架构重构、模型重构、认知重构。这四层的关系不是自下而上严格分隔的，而是认知重构处在最外层、包裹着其他三种重构，代码重构、架构重构、模型重构彼此之间也存在交叉影响，而非完全分离。这是因为软件系统本质上是一项”翻译”工作——把现实世界中的元素通过软件开发人员的抽象、映射到软件系统中。所以无论是代码的”破窗效应”还是架构的混乱，看似是系统本身的问题，本质上源于软件开发人员的个体熵增：一个不断熵增的架构师往往会导致一个熵增的架构，一个不断熵减的架构师则更容易创造出熵减的系统；同样，一个不断熵增的程序员正是引起代码”破窗效应”的根源。这解释了为什么认知重构是所有重构工作中最重要的那个——代码重构、架构重构、模型重构解决的是系统层面已经表现出来的混乱，而认知重构解决的是这种混乱真正的源头：开发人员自身认知水平的停滞或退化。要让架构师和程序员做到熵减，有两个具体动作：一是保持自律——放任系统中增加低劣的设计或代码，本质上和放任个人不好的习惯是一回事；二是持续学习——不断吸纳最新的技术和理念，用这种输入去对冲不断增加的熵增。可迁移启发：一个团队反复出现代码质量下滑、架构越改越乱的问题时，与其一味加强代码规范和架构评审这类”外部约束手段”，不如同时正视一个更根本的问题——团队成员本身有没有在持续学习、有没有在纵容自己写出”能跑就行”的低劣代码；系统的混乱程度，往往就是团队成员认知状态的一面镜子。

结构图：

flowchart TB
  A["认知重构(最外层,包裹其他三种)"]
  A --> B["代码重构"]
  A --> C["架构重构"]
  A --> D["模型重构"]
  B <--> C
  C <--> D
  E["软件是'翻译'工作:现实→抽象→系统"]
  E --> F["系统熵增的根源=开发人员的个体熵增<br/>(熵增的架构师→熵增的架构;熵增的程序员→破窗效应)"]
  F --> G["熵减两动作:保持自律+持续学习"]