今天早上的报纸上有一篇 Ben 写的精彩文章——全文请看 https://dev.to/dailycontext/design-for-churn-5c6h…

为频繁改动而设计

来源：https://dev.to/dailycontext/design-for-churn-5c6h AI 时代最大的设计转变，不在于谁来编写代码，而在于我们预期代码能存续多久。

在软件领域，代码的频繁改动一直被视为坏事。微软的研究人员多年前就指出 (https://www.microsoft.com/en-us/research/publication/use-of-relative-code-churn-measures-to-predict-system-defect-density/)，相对代码改动量可以预测缺陷密度。Adam Tornhill 专门写过一本名为*《你的代码如同犯罪现场》*的书 (https://pragprog.com/titles/atcrime2/your-code-as-a-crime-scene-second-edition/)，其中，频繁修改且复杂的文件是首要嫌疑对象。GitClear 的研究 (https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality)预测，AI 助手会使写成后两周内就被重写的代码占比翻倍，并将此描述为对代码质量的下行压力。这种直觉根深蒂固：不断修改的代码，就是原本写错了的代码。

但这种直觉来自一个编写代码成本高昂的世界。持久耐用，才能物有所值。当一个功能只需一个下午，而不是一个冲刺周期就能完成时，这笔账就反过来了。重写某个东西，往往比小心翼翼地保留它更便宜，而且今后只会越来越如此。

https://dev.to/dailycontext/design-for-churn-5c6h#codebases-are-gardens-now代码库如今成了花园

我们一直用建筑术语来描述软件：架构、地基、脚手架、承重墙。建筑理应稳固不动。

我认为，代码库正变得更像花园。具体来说，是种满一年生植物的花园。园丁每个季节都会重新种植一年生植物，没有人会因为一株番茄在十月枯死，就把它称为技术债。园丁真正的投入，是那些不会不断更替的东西：土壤、花坛、灌溉设施，以及角落里的橡树。良好的结构，恰恰能让重新栽种变得便宜。

频繁改动的代码本质上是用过即可丢弃的，而可丢弃并不意味着粗制滥造。它依然可以制作精良，只是并非为了长久留存。对于一年生植物般的代码，质量意味着它能完成自己的任务，边界处经过测试，并且可以被移除，而不会破坏周围的一切。

问题在于，我们还不清楚高质量的频繁改动应该是什么样。我们对质量的认知与长久存续纠缠在一起。我们会夸耀某段代码六年来一直运行，从未改动。因此，改动依然在发生，却是隐性的，而且总是落在最方便下手的地方。

https://dev.to/dailycontext/design-for-churn-5c6h#where-churn-actually-lands频繁改动究竟落在哪里

我查看了 Forem (https://github.com/forem/forem) 过去六个月的记录：563 次提交。改动最频繁的文件是 app/models/article\.rb，其中有 37 次提交涉及它。

我们的垃圾信息处理程序也位居前列，共涉及 13 次提交。对此，我很满意。垃圾信息是一种季节性作物。垃圾信息发送者不断改变策略，我们的代码也应该随之不断调整。

article\.rb 就是那棵橡树。如果橡树每周都被挖出来一次，就意味着新功能正在核心模型中扎根，因为那里是最容易种下它们的地方。这就是结构上的妥协。频繁改动本身不是问题。发生在承重部位、未经规划的频繁改动才是问题。

https://dev.to/dailycontext/design-for-churn-5c6h#designing-for-it为此而设计

以下是几个让频繁改动成为明确安排，而非偶然结果的想法：

**明确各层的定位。**清楚说明哪些是一年生植物，哪些是多年生植物。我们的 AGENTS\.md 已经在粗略地做这件事：它告诉 AI 助手，在核心身份验证、信息流排序和缓存流水线附近操作时要格外小心。这不应该只是一张警告标签，而应该体现在代码库的结构中。

**在花坛边界设立契约。**接口、模式定义、API 规范，以及固定行为而非实现方式的测试，就是多年生植物。它们背后的任何东西，都可以由人或智能体自由重写。

**降低移除成本。**检验一株一年生植物是否合适，就看能否在不扰动花坛的情况下将它拔除。如果某个东西注定要频繁改动，它就不该把触须伸进所有地方。

**按层衡量改动。**快速变化层中的频繁改动，是健康的表现。缓慢变化层中的频繁改动，才是警报。

https://dev.to/dailycontext/design-for-churn-5c6h#churn-is-a-design-input频繁改动是一项设计输入

无论如何，频繁改动都会发生。AI 已经让它成为我们所构建的大多数事物的默认变化节奏。我们可以继续将其视为一种症状，也可以将其视为一项设计输入，构建出让我们能够放心重新栽种的结构。

我承认，我一直更倾向于认为，频繁改动比软件设计的传统观念所暗示的更值得接受。在我的实践经验中，我从未觉得避免频繁改动是一件好事。过去，我还能理解争论双方的观点；如今，我坚定地站在这样一边：频繁改动与我们代码库和系统的质量及刚性呈正相关。

我宁愿打理花园，也不愿假装它是一栋建筑。