健康经济学指标

第 67 个主题，共 91 个· 软件工程与数字化交付

技术债 (Technical Debt)

技术债是代码库中过去为求权宜而做出的决策所隐含的未来成本：欠下的整改工作量（本金）以及它对交付持续施加的拖累（利息）。SQALE 之类的量化方法，把它从一个比喻变成了一项可计价的负债。

为什么重要

未经量化的技术债只是一句牢骚；一旦量化，它就是一份商业论证。行业基线数据（CAST Appmarq，1,400 个应用 / 5.5 亿行代码）：历史上大约每行代码 $3.61 的技术债本金，典型代码库的债务比率约为重建成本的 15–20%，相较之下常用的健康线是 ≤5%（SonarQube 的"A"评级）。卫生经济学的框架在这里恰好适用：技术债是一种慢性病——不加治疗就会持续进展，其"利息"会以更慢的交付速度和更高的缺陷率的形式复利累积，而整改工作会像预防与治疗争夺资源一样，与功能开发争夺产能。

计算方法

SQALE 本金   = Σ（每项违规的整改时间）× 开发者成本费率
技术债比率 (TDR) = 整改成本 / 重新开发成本 × 100
                    （SonarQube 评级：A ≤ 5%，B ≤ 10%，C ≤ 20%，D ≤ 50%）

利息（论证偿还合理性的关键数字）：
  年利息 = Δ交付速度 × 单位速度的价值
          + Δ缺陷率 × 每个缺陷的成本
偿还论证 = PV(周期内避免的利息) − 整改成本
          （需贴现——参见 discounting-and-time-preference.md）

本金陈述的是这笔负债本身；利息才是论证这项投资是否值得的依据。花 £500k 本金去避免每年 £40k 的利息是一笔糟糕的交易；去避免每年 £400k 的利息，则是一笔出色的交易。

算例

一个 40 万行代码的临床记录集成层：SQALE 本金 3,800 小时 × £75 = £285k；TDR ≈ 12%（C 级）。实测利息：接触该层的团队周期时长比整体基线长 40%，变更失败率高出 2 倍。该层每年吸纳 6,000 个开发工时：

利息 ≈ 6,000 × 0.40 × £75         = 每年 £180,000（速度拖累）
      + 12 次额外故障 × £8,000     = 每年 £96,000（返工/事故）
      ≈ 每年 £276,000

针对热点区域整改最严重的 30% 本金（£85k）→ 建模显示利息可降低 60%：
每年节省约 £166k。回本周期约 6 个月。

热点定位很关键：债务利息集中在"变更频率 × 债务密度"最高的地方——整改很少被触碰的债务毫无收益，就像治疗一种本来永远不会进展的病症（参见预防经济学）。

与软件工程的关联

能提升技术债论证质量的卫生经济学借鉴：把整个代码资产表达为一份负担清单（类似 DALY 的思路——损失的"健康工程年"分布在哪里？）；诚实地用进展数学来论证偿还的合理性（通常是"有成本效益"，而非"能省钱"）；按严重程度短缺调整系数为最糟糕系统的整改加权；提交大型整改提案时，须附上一份能经受住避免的下游成本规则检验的抵消分析——按概率加权、经过贴现、只计一次。

陷阱

  • 只报告本金：一个吓人的大数字，如果没有利息估算，什么都论证不了。
  • 把工具生成的债务数字直接当真：SQALE 计数的是规则违规；它会漏掉架构层面的债务（代价最高的那种），却会计入一些琐碎小事。
  • 零债务乌托邦主义：最优的债务水平并非零——债务是一种杠杆；问题在于利率是多少。
  • "重写能避免这一切"：重写提案必须通过同样的抵消规则检验——反事实成本、概率、贴现，一样都不能少。

参考来源