推文

@yibie · 2026-10-15 07:47

AI 时代最大的设计变化，不是谁在写代码，而是代码被期望活多久。 在软件里，churn（反复改动）一直是个脏词。微软的研究者多年前就证明过，相对代码 churn 能预测缺陷密度；Adam Tornhill 写了整本《Your Code as a Crime Scene》，把最常改、最复杂的文件列为头号嫌疑人；GitClear 的研究则预测 AI 助手会把"写完两周内就被重写"的代码比例翻倍，并把这当成对质量的向下压力。这个本能很深：代码一直在改，说明它本来写错了。 但这个本能来自一个写代码很贵的世界——耐用，才值回票价。当做一个功能只要一个下午而不是一个冲刺，算术就反过来了：重写往往比小心保住更便宜，而这只会更真。 代码库正在变成花园，准确说是种满一年生植物的花园。园丁每季重栽一年生植物，没人会因为番茄十月会死就叫它技术债——园丁真正的投资放在不会周转的东西上：土壤、花床、灌溉，还有角落里那棵橡树。好的结构恰恰是让重栽变便宜的东西。 大量 churn 的代码基本是一次性的，而一次性不等于草率。它照样可以做得很好，只是不是为长久而做。对一年生植物来说，质量意味着：它把活干了，它在边界上被测过，它被拔掉的时候不会把周围一起撕开。 问题是我们还没有一幅"高质量 churn"长什么样的图。我们对质量的想象和"长寿"缠在一起，会炫耀某段代码六年没被动过。于是 churn 照样发生，只是偷偷发生，落在最方便的地方。 它实际落在哪：我看过 Forem 最近六个月——563 次提交，改动最多的文件是 app/models/article.rb，37 次提交里动过它。我们的反垃圾处理器也上榜，13 次，这个我挺高兴：垃圾信息是季节性作物，发垃圾的人一直在换手法，我们的代码也该跟着换。而 article.rb 是那棵橡树——橡树被每周挖一次，说明新功能都往核心模型里扎根，因为那是最好落脚的地方。这就是结构上的妥协。churn 不是问题，承重位置上没计划的 churn 才是。 几条把 churn 变显式而非意外的做法： 给层命名。明说哪些是一年生、哪些是多年生。我们的 AGENTS.md 已经做了个粗糙版本——叫 AI 助手小心核心鉴权、feed 排序和缓存管线。但这不该只是一张警告标签，它应该是代码库的形状。 把契约放在花床边上。接口、schema、API 规格，以及那些钉住行为而非实现细节的测试，是多年生的。它们背后的一切都可以被自由重写，不管动手的是人还是 agent。 让移除变便宜。检验一年生植物好不好，就看拔掉它会不会惊动整张床。如果某个东西本来就该 churn，它就不该在到处都有藤蔓。 按层量 churn。快层里高 churn 是健康的信号，慢层里出现 churn 才是警报。 作者自己交代了一句：他一向觉得 churn 比传统软件设计所暗示的更可接受，过去还两边都看得见，现在坚定站在"churn 与代码库和系统的质量、刚性正相关"那一边。他的收尾是：我宁愿照料花园，也不愿假装它是一栋建筑。 我们的判断：这解释了为什么 agent 改代码动不动就伸进核心文件——它默认往最容易落脚的地方扎根，而仓库里没有人写明哪一层是一年生的。把这件事写进仓库，比事后靠 review 去拦有用。 原文：https://dev.to/dailycontext/design-for-churn-5c6h #Agent #软件设计 #工程文化

曝光 36 · 评论 0 · 点赞 0 · 书签 0