https://blog-architectview.pages.dev/tags/%E4%BB%A3%E7%A0%81%E8%B4%A8%E9%87%8F/ Recent content in 代码质量 on 架构视界 Hugo zh-cn © 2026 架构视界 Architect View Fri, 15 May 2026 00:00:00 +0000 https://blog-architectview.pages.dev/posts/tech-debt-topology-and-governance/ Fri, 15 May 2026 00:00:00 +0000 https://blog-architectview.pages.dev/posts/tech-debt-topology-and-governance/ <blockquote> <p>Ward Cunningham 在 1992 年提出「技术债务」这个概念时，他可能没想到三十年后这个词会成为每一个技术团队的噩梦。技术债务不像金融债务那样可以精确计算，它更像是一种熵——在看不见的地方悄悄增长，直到系统变得不可维护。</p></blockquote> <h2 id="技术债务不是一种债">技术债务不是一种债</h2> <p>很多人把技术债务理解为「欠下的代码质量」，觉得只要花时间重构就能还清。这个理解有一个根本性的错误：<strong>技术债务不是贷款，而是复利。</strong></p> <pre tabindex="0"><code>金融债务： 借 100 万，年利率 5%，每年还 5 万利息 债务总额是确定的，还款计划是可预测的 技术债务： 写了一段快速但丑陋的代码来赶 deadline 第一个月：需要在这段代码旁边加个功能 → 多花了 2 小时 第三个月：新人入职看不懂这段代码 → 多花了 2 天 第六个月：这段代码的 Bug 引发了线上事故 → 多花了 1 周 第十二个月：这段代码和其他模块的耦合太深，无法重构 → 被迫放弃 技术债务的利息不是线性的，而是指数增长的 </code></pre><p>这就是为什么技术债务不能「等有空了再还」——因为等你有空的时候，利息可能已经超过了本金。</p> <h2 id="技术债务的四种类型">技术债务的四种类型</h2> <p>Martin Fowler 在《Refactoring》中把技术债务分为四个象限：</p> <pre tabindex="0"><code> 鲁莽的 审慎的 ┌──────────────────┬──────────────────┐ 故意的 │ &#34;我们不需要测试&#34; │ &#34;我们知道这里耦合 │ │ &#34;先 copy paste │ 太紧，但现在重构 │ │ 以后再重构&#34; │ 会延误发布，下个月 │ │ │ 专门处理&#34; │ ├──────────────────┼──────────────────┤ 无意的 │ &#34;什么是分层？&#34; │ &#34;我们现在才理解 │ │ &#34;把 SQL 写在 │ 应该怎么做&#34; │ │ Controller 里&#34; │（随着认知深入发现 │ │ │ 之前的设计有问题） │ └──────────────────┴──────────────────┘ </code></pre><p><strong>鲁莽且故意的债务</strong>最危险——团队明知故犯，而且不考虑后果。</p>