ARTICLE · 软件编程
将可理解性作为架构特性：无法理解的系统无法安全演进
一语总结本文提出可理解性应作为演进式架构的核心特性，系统只有被团队真正理解才能安全演进，并针对知识碎片化、人员流动和生成式 AI 三大侵蚀因素，给出了度量指标与构建实践。
文章以演进式架构为背景，论证可理解性（comprehensibility）不是软性追求，而是系统能否安全吸收变更的架构特性。作者引用 Peter Naur 的「编程即理论构建」和 Margaret-Anne Storey 的认知债务/意图债务概念，指出系统不仅包含代码，还包含团队对代码的心理模型，而这一模型会随时间悄然流失。文章识别了三股侵蚀力量：去中心化决策导致知识碎片化、人员流动带走理论、生成式 AI 压缩理解环节导致「不理解就交付」。随后提出一套度量体系——PR 规模、审查分布、DOA/卡车系数、入职摩擦、ADR 缺失率、领域泄露等——以及构建实践：设计评审优先于代码审查、工程师用自身语言解释变更、跨模块结对与轮换、有界上下文上的共同契约理解。核心论点是：理解债务会产生利息，只有将有意识的理解构建嵌入流程，演进式架构的承诺才能真正兑现。
- 可理解性是演进式架构的固有特性，而非软性追求。
系统包含代码及其背后的心理模型（理论），该理论在团队中被接受的广泛程度决定系统能否安全演进；不可理解的系统无法安全变更。
- 知识碎片化、人员流动和生成式 AI 是三大侵蚀力量。
去中心化决策带来知识孤岛，人员离职带走理论，GenAI 压缩理解环节导致「不理解就交付」，三者共同扩大理解债务。
- 可理解性流失可通过适应度函数和监控指标量化。
PR 规模、审查分布、DOA/卡车系数、入职摩擦、ADR 缺失率、领域泄露等指标可作为先行信号，阈值应视为调查触发点而非硬性目标。
- 事前理解比事后审查更重要，设计评审优先于代码审查。
工程师在设计阶段主动构建心理模型，才能确保人类掌控系统演进方向；事后理解意味着设计权让渡给 LLM 的统计学默认。
- 理解债务会产生利息，必须持续维护而非一次性清偿。
通过跨模块结对、轮换、有界上下文上的共同契约理解，将可理解性嵌入流程，使其成为针对未加入团队工程师的机制。
将可理解性作为架构特性：无法理解的系统无法安全演进
文章以演进式架构为背景，论证可理解性（comprehensibility）不是软性追求，而是系统能否安全吸收变更的架构特性。作者引用 Peter Naur 的「编程即理论构建」和 Margaret-Anne Storey 的认知债务/意图债务概念，指出系统不仅包含代码，还包含团队对代码的心理模型，而这一模型会随时间悄然流失。文章识别了三股侵蚀力量：去中心化决策导致知识碎片化、人员流动带走理论、生成式 AI 压缩理解环节导致「不理解就交付」。随后提出一套度量体系——PR 规模、审查分布、DOA/卡车系数、入职摩擦、ADR 缺失率、领域泄露等——以及构建实践：设计评审优先于代码审查、工程师用自身语言解释变更、跨模块结对与轮换、有界上下文上的共同契约理解。核心论点是：理解债务会产生利息，只有将有意识的理解构建嵌入流程，演进式架构的承诺才能真正兑现。
文章金句
"一个不被理解的系统无法安全地演进。
"系统不仅包含代码，还包含程序员心中所秉持的底层理论。
"理解债务（系统实际状态与团队对其理解之间的差距）就是一项会产生利息的负债。
"如果代码审查和验证是唯一需要我们理解的环节，那么真正的理解就永远无法形成。