将可理解性作为架构特性：无法理解的系统无法安全演进

本文由 InfoQ 认证架构师在线活动 "的参与者撰写。这是他们工作的集大成之作，反映了该活动的参与者在 AI 与现代软件架构的交叉领域中所获得的集体见解。 可理解性问题 在复杂系统领域有丰富经验的团队，想必都曾遇到过处理生产环境故障的情况：在处理过程中，大部分时间都花在弄清楚系统的各个部分如何连接以及系统实际做了什么操作上，而不是查找 Bug。最终，团队只能通过翻阅代码来厘清依靠团队集体记忆无法明确回答的问题——即系统的行为方式。出现这一问题的原因在于，对系统的理解从未超越某些特定的个人，也未能扩展到团队中的其他成员。 在演进式架构中，系统应该设计成可以吸收并适应不断变化的需求和环境。但要真正实现这种适应性，团队成员需要对系统本身有深刻的理解。正如 Peter Naur 在《 编程即理论构建 "》一书中所论述的那样，仅仅理解代码是不够的；你必须理解构建该代码的程序员心中所秉持的底层“理论”。这里的“理论”是指程序员为理解程序运行机制而构建的心理模型。他指出，系统不仅包含代码，还包含这一理论。因此，该理论在团队中被接受的广泛程度和持久性是系统本身的一个属性。Margaret-Anne Storey 在其论文“ 从技术债务到认知债务与意图债务：人工智能时代软件健康的新思考 "”中进一步阐述了这一观点。她在文中定义了三种截然不同的系统债务：技术债务、认知债务和意图债务。认知债务是指对系统的共同理解悄然流失（即诺尔所说的“理论”流失）；意图债务则是缺乏对系统现状形成原因的合理依据。与性能和可用性等特性不同，这一特性会随着时间的推移悄然恶化，而一个不被理解的系统无法安全地演进。由于人类的理解既包含“是什么”也包含“为什么”，所以它是解决认知债务和意图债务的直接解药，必须被视为演进式架构中固有的架构特性。 削弱可理解性的三大因素 在由多个团队维护的复杂系统中，集中式决策往往会导致瓶颈和知识孤岛。决策需要经由少数人逐一审批，知识也因此集中在了这些人手中。为消除这些瓶颈并真正地实现演进式架构，组织可以转向去中心化的架构决策模式。虽然这能优化流程，而且各团队能在各自的子领域中积累起深厚的专业知识，但整体视图会因此变得支离破碎。各团队可能会了解自身服务的运作方式，却可能忽略了系统边界最初划定的“原因”。在缺乏共同治理和实践的情况下，各团队的理论会逐渐背离，导致组织内部的知识碎片化加剧。 团队人员流动也加剧了这一问题。当人员离开团队时，他们会带走部分“理论”。新入职者必须从头重建理论体系，而现有的文档通常只记录“是什么”，而非“为什么”。由于缺乏关于某些边界为何存在的历史背景，所以他们可能会退而求其次，采取战术性修补，而非进行符合原始设计的系统性改进。久而久之，这将侵蚀架构的完整性。 在这三股力量中，最新且发展最快的是生成式人工智能（GenAI）。它减少了以往为获得可理解性这一副产品所需的实现工作量，但正是这些工作量在开发者心中构建起了系统的思维模型。在生成式人工智能于软件工程领域崭露头角之前，可理解性是在设计、实现和验证阶段自然形成并得到强化的。随着这项技术的日趋成熟，交付压力也比以往任何时候都更加严峻。我们发现，这种“不理解就交付”的倾向正悄然渗入企业级软件领域。在向客户进行功能演示时，我们团队中一位经验丰富的工程师不得不花费大量的时间来理解她一周前交付的一段代码是如何工作的，因为她从未建立起对这段代码的心理模型。虽然这段代码通过了所有的质量检查，但在演示过程中，“理解债务”才首次显现出来。 Arvind Narayanan 和 Sayash Kapoor 最近发表的一篇 文章 "指出，软件工程师的工作如同一个“决策-执行-交付”的三明治，而理解是这三层的先决条件。 生成式人工智能压缩了中间层。我们认为，过去贯穿这三个层的理解，现在应当有意识地在两端构建。对于系统中比较复杂的部分，其可理解性必须在这两个阶段形成——即“生成”阶段之前和之后。软件工程师必须在这些阶段投入精力，将设计与现有系统的结构联系起来，组织并构建一个心理模型。 知识碎片化、团队人员流动以及 AI 引发的变更——这些因素以不同的速度侵蚀着可理解性，最终导致系统无法安全地进行变更。 检测和度量可理解性的流失 架构师和技术负责人可以通过监控若干关键指标，量化系统可理解性的流失。实现这一目标的天然工具是适应度函数——它们使架构师能够表达重要的架构特性并自动进行验证。自动化的适应度函数可以度量理论流失的一些先行指标，但无法度量对设计意图本身的理解程度。没有任何管道检查能确认人类是否理解某项变更存在的理由。自动化任务是检测理论在什么条件下出现了衰减；而验证变更是否符合设计意图，以及是否有人真正地掌握了其背后的理论，则属于下一节所述的人工检查点。 因此，我们有意扩展了该术语的内涵。下文列表中的“适应度函数”评估的是围绕代码的社会技术系统，其中只有一部分可以完全自动化，其余的则是监测指标而非可执行的检查。在某些情况下，这是主动选择而非限制。关于人的指标在强制执行时会改变行为——阻挡 PR 的门槛可能会被钻空子绕过——当钻空子很难或无害时才强制执行，否则仅进行监控。将阈值视为调查的触发点，而非目标。当存在可绕过的门槛时，应追踪豁免和覆盖情况，以便修正阈值或改进团队实践。 图1：可理解性必须在执行阶段之前和之后形成（图片由作者使用 draw.io 制作） 代码审查动态 拉取请求（PR）是知识共享的主要途径。审查指标出现异常往往意味着共同理解出现了问题。请留意以下早期预警信号： PR 规模过大：当 PR 规模过大以至于无法进行审查时，其本应承载的知识流动便无法实现。可以通过阻止过大的 PR 来落实这一要求（根据具体情况定义阈值）。请作者将 PR 拆分，并在设计审查阶段尽早发现这一问题。 智能代码审查工具：不要让智能代码审查成为 PR 的唯一审查者——它可以作为第一位审查者，但必须由人工审查者进行后续审查。可以通过“代码所有者”（CodeOwners）等策略来落实这一要求。 代码审查失效：当审查工作量集中在少数人身上，或者组织氛围导致审查人员不敢向资深成员提供恰当的反馈时，审查便沦为走过场。这种情况只能通过监控来发现。追踪已获批准的 PR 中未附有实质性评论或仅标注 “LGTM” 的比例，以及团队内审查任务的分布情况。轮换审查人员，并赋予团队中每个人（无论职位高低）审查 PR 的权限。要明确传达一个理念，鼓励对任何作者的设计或代码提出质疑，包括架构师的。 设计评审缺失：对于影响范围广泛的代码变更——即本质上比较复杂的核心模块和接口——无论变更规模大小，都应该先进行设计评审。由于这一点难以强制执行，所以应追踪那些涉及核心模块且未经事先设计评审就被合并的 PR。要求作者就设计变更向团队作一次说明，以弥补缺失的设计评审。 知识分布 当关键的上下文信息被极少数工程师垄断时，项目就会陷入停滞。要警惕那种只有一个人掌握系统设计意图的情况。听到“我们等 Dave 吧”这种说法时，团队应该立即提高警惕。作者贡献度（ DOA "）衡量的是个人在系统创建过程中所完成的工作量。较高的 DOA 意味着知识集中在少数人手中。请注意，DOA 存在局限性；应该将其看成是可参考的众多信号之