技术债务不是隐喻，它是导致你的迁移失败的原因。
Source: Dev.to
我最近阅读了 Dave Farley 的《Managing Technical Debt》指南。这是一篇必读文章，因为它把债务严格视为商业风险，而不仅仅是开发者的抱怨。
我对 Farley 概念的看法
- 在过去的二十年里，我一直在修复那些“快速迭代、随意破坏”的系统。
- 我在与遗留 Java 单体应用作斗争并将其迁移到 AWS 的过程中，实践了 Farley 的思想。
位腐（Bit Rot）
Farley 提到了 “Bit Rot”——软件会随时间退化的概念。代码本身不会生锈，但被忽视会导致退化。
厨房类比
如果你做一顿五道菜的盛宴，却从不洗锅或擦台面，最终你将无法继续烹饪。你被凌乱所瘫痪。
在实际工作中，团队常常：
- 将 Java 应用 Lift‑and‑shift 到 AWS，却不进行重构或模块化。
- 把一次简单的 JDK 升级当作“现代化”。
结果： 一个 15 年历史的单体运行在昂贵的 EC2 实例上，每一次安全补丁都有可能破坏无关的模块。
我的准则： 如果你没有让代码比你接手时更好，那它已经在腐烂。
配置债务（Configuration Debt）
在 Java 世界里我们学会了避免 spaghetti 代码；现在我看到的是 “Spaghetti Infrastructure”。
- 通过 UI 手动定义安全组。
- 在控制台中设置 Lambda 触发器，却没有文档。
- Terraform 状态与实际环境不同步。
这种 配置债务 可能比代码债务更糟，因为它可以导致整个环境崩溃，而不仅仅是单个功能。
如果我抓到开发者在 AWS 控制台手动更改基础设施设置，那就说明出现了问题。不是因为我挑剔，而是因为这种手动改动对下一个运行部署流水线的人来说是一个计时炸弹。
AI 生成代码与高速债务
Copilot、ChatGPT 等工具非常强大，但其影响取决于团队的纪律性。
- 有纪律的团队： 将这些工具视为提升生产力的强力武器。
- 无纪律的团队： 成为高速债务的生成器。
我看到很多 Pull Request 里充斥着 AI 生成的模板代码，作者显然没有仔细阅读。
- 能用吗？也许可以。
- 高效吗？很少。
- 能处理边缘情况吗？根本不行。
记住： “Bit Rot” 源于忽视。未经严苛重构和测试就生成 AI 代码，会把忽视的速度提升 10 倍。你并不是在“更快编码”，而是在自动化生成遗留代码。
我的 AI 代码准则
把 AI 生成的代码当作喝醉的实习生写的代码——要多审查两遍。
“我们以后再写测试。”
不，你不会。 我从未见过有团队在功能上线后补写单元测试。
测试债务
测试债务会扼杀开发速度。没有可靠、快速、自动化的测试套件（而不是手动 QA），团队会害怕改动代码。恐惧导致重构停滞，进而加速位腐——形成恶性循环。
实际可操作的要点
- 技术债务是不可避免的，但它必须是有意识的选择（像按揭贷款），而不是因无能而产生的（像赌博）。
- 持续重构。
- 把一切都写进代码，尤其是基础设施。
- 不要让 AI 写你不理解的代码。
- 投资自动化测试，以保持高变更速度。