变更耦合：为什么一处一行的修复会牵动十个文件

# 变更耦合：为什么一处修改要动十个文件 | 知识库 来源：https://kb.buildingbetterteams.de/docs/technology-product/Software/Change-Together/ 先谈权衡 变更耦合是一种帮助决策者理解系统的工具，而不是用来优化的质量指标。追求耦合的完美对齐并不是目标——真正重要的是理解系统的真实结构。每一个架构决策都涉及权衡，必须放在具体情境中去考虑。 ## 零散的变更问题（https://kb.buildingbetterteams.de/docs/technology-product/Software/Change-Together/#the-scattered-change-problem） ### 痛点（https://kb.buildingbetterteams.de/docs/technology-product/Software/Change-Together/#the-pain-points） 我们都经历过这种情况：你只想加一个小功能，结果却要改动分布在 6 个目录里的 12 个文件。本应是一次简单的 bug 修复，却引发了一连串你从未预料到的改动，更糟的是——你甚至已经开始习以为常并深恶痛绝。当你发现自己的代码评审中，有一半的文件按理说与本次改动毫无关系时，变更耦合的问题就变得显而易见了。 糟糕的变更耦合会拖慢我们阅读和编写代码的速度，但更严重的是，累积起来的认知负担最终会压垮那些试图做出改动的人。 忽视变更耦合会带来令人不快的意外。我们通常会认为，如果两段代码互不调用、互不引用，它们就应该是彼此独立的。然而，变更耦合告诉我们：那些看起来毫无关联的代码，往往出于隐藏的原因仍需同步修改，系统才能正常运转。这种现象既可能出于技术原因，也可能出于业务逻辑原因。改了 X 就意味着要改 Y，而不论代码本身表面上暗示了什么。静态代码分析无法直接检测出这类依赖关系，但通过长期在同一个代码库中工作，我们是可以逐渐培养出这种直觉的。 如果你想提升项目的变更速度，理解自己软件的变更耦合就至关重要。 ## 属于哪种耦合？（https://kb.buildingbetterteams.de/docs/technology-product/Software/Change-Together/#what-kind-of-coupling） 我们编写的代码，仅仅是编写代码时需要思考的内容的表层。 ### 耦合存在多种类型（https://kb.buildingbetterteams.de/docs/technology-product/Software/Change-Together/#many-types-of-coupling-exist） - **物理耦合（Physical Coupling）**：代码在文件结构中的距离远近 - **逻辑耦合（Logical Coupling）**：在概念上相互依赖的函数 - **时序耦合（Temporal Coupling）**：必须按顺序发生的事情 - **数据耦合（Data Coupling）**：共享的数据结构与格式 - **控制耦合（Control Coupling）**：一个模块控制另一个模块的行为 - **变更耦合（Change Coupling）**：经常一起发生变更的代码（本文的重点） 并非所有耦合都是坏事。耦合提供了必要的结构，但过多的耦合会阻碍变更。就像一台汽车引擎——有些部件必须耦合在一起，而另一些则必须保持独立。你不会希望雨刮器与刹车系统耦合在一起。 不存在一个理想的耦合比例可供优化。0% 和 100% 的耦合同样都是问题。0% 意味着什么组件之间都无法协同工作，100% 则比一团乱麻还要糟糕。这项分析是一种帮助你和团队理解系统中各种作用力、从而指导架构决策的认知工具，而不是让你去追逐完美的指标或彻底消除耦合。 变更耦合之所以有意思，是因为它无法通过阅读最新的代码来检测，它需要变更历史。它揭示的是系统演化的现实，而不是代码之间当前的接线方式。它既能揭示看似无关的代码之间出人意料的关联，也能帮助你清理那些杂乱的"垃圾场"（通常是 `/utils`）——所有难以归类的东西都往里扔，但没人清楚哪些东西应该被移出去、该移到哪里。 最后需要理解的一点是：变更耦合关注的是"**一起发生变更**"的代码，而不是"**会变更**"的代码与"**不会变更**"的代码之间的对比。当代码发生变更时，它是与其他代码一起变，还是各自独立地变？这提供的洞察与"这段代码究竟会不会变"截然不同——后者可能说明的是演化上的稳定性（那本身就是一个很深的话题，本文不作展开）。 ## 一起变化的东西（https://kb.buildingbetterteams.de/docs/technology-product/Software/Change-Together/#things-that-change-together） 一起变化的东西就应该放在一起 变更耦合揭示了系统想要分裂与合并的断层线。可以把它想象成引力或磁力。经常一起变更的代码之间共享着概念上的"重量"，这股力量会把它们拉向同一个位置。 **永不一起变更的代码** 代码之间即使物理距离很近，却从不一起变更，这说明它们之间可能存在人为的耦合，而这种耦合可能已经不再有任何实际作用。 ### 物理耦合 vs 变更耦合矩阵（https://kb.buildingbetterteams.de/docs/technology-product/Software/Change-Together/#the-physical-vs-change-coupling-matrix） 如果把"物理"理解为代码在文件中的位置，我们就可以用代码的物理耦合与变更耦合做对比，从而思考我们的代码可能落在哪些情形中，以及它整体上是否处于可维护、低认知负担的状态。这个 2×2 矩阵仅仅是用来辅助理解的工具，并非官方的"完美评判标准"，但它依然极其有用——常常能直接指出需要重点关注的问题区域，甚至告诉你该如何修复这些问题。它甚至可能显示出：某些代码虽然在其他指标上看起来有问题，但就变更耦合而言其实是健康的。如果你打算对系统进行一次概念层面的重构，这一点可以为你的设计提供参考——现有系统可能已经在某些重要之处做对了。 MODIFY ##### 🔴 考虑合并 高变更耦合，低物理耦合 经常一起变更却分散在不同位置的代码。这些函数在告诉你：它们想要成为邻居。 **示例：** 认证逻辑散落在 utils/、components/ 和 services/ 中，却经常需要一起修改。 MONITOR ##### 🟢 对称耦合 高变更耦合，高物理耦合 经常一起变更、也放在一起的代码。这是更理想的状态。你的物理代码布局与代码的实际变更模式是对称的。 **示例：** 支付处理相关的函数位于同一个模块中，并且在开发新功能时总是同步演进。 MONITOR ##### 🟢 对称解耦 低变更耦合，低物理耦合 很少一起变更、也不存放在同一个位置的代码。这是干净的分离，反映了真实的独立性。 **示例：** 数据库连接工具与 UI 组件各自独立演进，分别保存在不同的模块中。 MODIFY ##### 🔴 考虑拆分 低变更耦合，高物理耦合 放在一起、却很少一起变更的代码。可能是历史上某些决策造成的非必要耦合。 **示例：** 一个"utils"模块，里面装满了互不相关的辅助函数——每当团队想不出更好的归处时，就随手丢进来。 ### 示例：支付系统（https://kb.buildingbetterteams.de/docs/technology-product/Software/Change-Together/#example-payment-system） 在这个例子中，团队认为他们的支付系统已经实现了良好的关注点分离。他们有一个模块负责实际的资金交易，另一个模块负责计算手续费，第三个模块负责将手续费流向这笔特定支付交易。 设计的初衷是：团队每次只需要修改一个模块，通常只是手续费引擎（Fee Engine）。但开发者们感觉到，每次手续费引擎的改动都会以某种方式波及到全部三个模块。一份变更分析报告证实，他们确实经常同时修改这三个模块。概念层面的设计是合理的，但在查看这三个模块之间的变更耦合之后，我们甚至还没开始读代码，就已经有了一个相当强烈的信号：这里有问题。 "一起变化的东西就应该放在一起"并不是字面意义上地要求把这三个模块合并进同一个文件。它更像是一条认知上的指引：促使我们去追问，究竟是什么原因让这些模块被"磁化"到了一起。 真正实现中存在如此耦合的原因有很多。下面举一些例子： - 围绕交易日志的合规规则（Compliance rules）逻辑在最初的实现中没有被考虑到；持久化逻辑在交易处理器中，但它需要更新一个用于查询原因代码的查找表。 - 某些国家/地区不同的费率结构要求交易数据块中包含特殊的数据结构，在这个金融系统中，它无法只是一个单一的扁平数字。 - 有些商户协议中约定了手续费上限，为了确保不会产生超额费用，交易处理器中设置了手续费上限作为安全保护。 - 数据库结构以一种不可见的方式把这三个模块耦合在了一起。 - 交易模块被过度扩展，用来管理真实交易和内部的"客户信用账户"。 - ……我们可以整天不断地设想这样的场景。真实系统就有真实的问题。 把三个模块合并成一个听起来很诱人，但这样做会牺牲其他有价值的代码质量和架构关注点，很可能产生一团单体的乱麻，其糟糕程度丝毫不亚于现在。更好的做法是：重新审视这些变更是如何被引入的，并把共同的部分抽取出来，或者以注入的方式把共同部分植入。一个好的方法（还有很多其他方法，本文不会一一展开）是使用依赖倒置（Dependency Inversion，这与依赖注入 Dependency Injection 并不是同一回事，但通常会*使用*依赖注入）来把业务规则与抽象的机制层隔离开。就像使用可更换的钻头，而不是为每一种类型和尺寸的螺丝都去买一把新电钻。 当然，也有很多时候，把两段代码合并为一，甚至是替换掉系统的一部分，确实是完全正确的做法。你的具体耦合难题是什么，以及你究竟在优化什么，这些情境可能导向截然不同的解决方案——包括：如果权衡下来是值得的，那就保留这些存在变更耦合的代码！环境越是不稳定、业务领域的界定越是模糊，今天为真的事情就有可能很快翻转为假。 然而，应对变更耦合的关键，既不是每天用蛮力和它正面对抗，也不是制造一个单体巨石。同样地，把所有东西拆分成独立模块或微服务也无法解决这个问题。请记住，变更耦合是指软件在事实上发生了同步变更，它超越了编程语言、代码仓库、部署方式和接口的边界。如果你同时改变了两件事，那它们就是存在变更耦合——不论这两件事是什么、也不论它们位于哪里。 变更耦合分析并不给出解决方案——它揭示的是作用于你系统之上的吸引力与排斥力。理解这些作用力，能帮助你做出明智的架构决策，而不是与代码库的自然演化方向背道而驰。 ## 人们容易犯的错误（https://kb.buildingbetterteams.de/docs/technology-product/Software/Change-Together/#what-people-get-wrong） ### 银弹陷阱（https://kb.buildingbetterteams.de/docs/technology-product/Software/Change-Together/#the-silver-bullet-trap） 当团队遭遇变更耦合问题时，他们通常会倾向于： - **事件驱动架构（Event-driven architectures）**："我们要用事件来解耦！"（但事件同样可能制造出多种耦合形式，尤其是当"这些东西必须一起变更"的本质问题没有被解决时，问题反而被塞进了更加分散的方案之中） - **微服务（Micro-services）**："拆分成独立的服务就能解决！"（但逻辑耦合依然存在——就像事件一样，需要一起变更的东西仍然需要一起变更，即使它们位于不同的代码仓库、通过网络发送消息、运行在不同的运行时环境中） - **接口的过度扩张（Interface proliferation）**："多增加一些接口和 API 就会有帮助！"（这个感觉是对的，因为 API 经常出问题，甚至按照"接口隔离原则（Interface Segregation Principle）"之类的概念听起来也像那么回事；但如果等式两端都需要变更，那么在两段东西之间增加更多形式化的接口，并不会让变更耦合消失） - **理论上纯粹的领域边界（Theoretically pure domain boundaries）**："我们要设计出最理想的业务边界！"（领域建模确实能提供关于业务复杂性的关键洞见，但一味追求某个最终的"正确"领域结构，等于忽略了业务现实本身就在不断变动。团队会重组，优先级会演化，而康威定律（Conway's Law）确保了：即便是最精心设计的边界，也会被人们实际协作方式的持续变化所重塑） - **架构模式的教条主义（Architecture pattern orthodoxy）**："这次我们要架构得漂漂亮亮！"（但如果不去用你实际的变更耦合情况和团队动态来衡量这些模式的有效性，只是僵化地照搬模式处方，往往会产生比它们原本要解决的问题更多的协调开销） 以上每一种技术都*有可能*帮上忙，但魔鬼都藏在细节里。而且这些技术也常常会变成一场失败的"大型重构"运动。 然而，导致项目失败的并不是这些技术本身。失败的原因是它们忽略了引导决策所必需的一个关键要素。几乎可以肯定的是：忽视变更耦合，你的项目就难以达成所有人都期望的目标（而且通常这些项目背后都牵扯着不小的政治资本——高层领导者若是在没有变更耦合这种细微考量的情况下贸然采用常见的技术方案，将会损失巨大）。 ### 认知负担（https://kb.buildingbetterteams.de/docs/technology-product/Software/Change-Together/#cognitive-load） 变更耦合糟糕的系统的本质特征在于：开发者需要做的改动被分散、割裂地散布在整个系统之中，甚至一次改动的规模都超出了它本应有的大小。这给开发者带来了巨大的认知负担。他们必须在一个大得多的表面上追踪改动，在脑海中同时应付多个互不相关的系统。随着他们追踪一张不断扩张的依赖之网，复杂性会成倍地累积。很容易出现这样的情况：程序员对其中许多区域都很陌生，他们必须停下来去弄清楚：在这个系统里要做的那一小处改动，在逻辑上如何与许多意料之外的其他系统耦合在一起。 这种不断延伸的事实之网又暴露出更多的事实之网，最终可能导致一种"变更瘫痪"：考虑清楚究竟哪些文件需要改、该怎么改，本身就已经过于复杂了。确实有一些技术可以辅助混乱代码的重构工作，但这些工作非常耗时，而且往往更好的办法是从一开始就避免陷入这样的境地。 一个耦合糟糕的系统会迫使开发者在弄清"到底需要什么样的修复"的过程中，进行指数级的探索工作，以及在真正做出改动时同样巨大的投入。因此，耦合糟糕的系统对开发者生产力而言，是一种巨大的、本不必要的浪费，在追求生产力提升的过程中值得认真对待。 为了让这个问题更加具体，不妨设想两个项目，它们要做一次逻辑上类似的变更。在其中一个项目中，变更是内聚的——改动的区域集中而清晰。在另一个项目中，改动则散落在整个项目里，而重要的部分还被隐藏在看似毫无关联的文件之中。 ### 内聚的变更 集中的改动区域 #### 项目结构 **涉及文件：** 3 **涉及目录：** 1 **上下文切换：** 1 **预计耗时：** 2 小时 ### 非内聚的变更 散落在整个项目中 #### 项目结构 ├── session\.js 埋没在大量毫不相关的内容之间 ├── middleware\.js 埋没在大量毫不相关的内容之间 └── serializers\.js 埋没在大量毫不相关的内容之间 ├── email\.js 埋没在大量毫不相关的内容之间