健康经济学指标

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

技术债务

技术债务是指代码库中过去权宜之计的决策所暗含的未来成本：所欠下的补救工作（本金），以及它对交付所施加的持续拖累（利息）。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%）

利息（真正为偿还投资提供论证依据的数字）：
  年利息 = Δ交付速度 × 每单位速度的价值
         + Δ缺陷率 × 每个缺陷的成本
偿还论证 = 现值(时间范围内被避免的利息总和) − 补救成本
          （需贴现——参见discounting-and-time-preference.md）

本金陈述的是负债本身；而利息才是这项投资论证的核心。花£500,000本金去避免每年£40,000的利息，是一笔糟糕的交易；若能避免每年£400,000的利息，则是一笔出色的交易。

实例演算

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

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

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

热点定位至关重要：债务利息往往集中在"变更频率 × 债务密度"最高的地方——补救那些很少被触及的债务毫无收益，就如同治疗一种本来根本不会进展的病症（参见预防经济学）。

与软件工程的联系

能提升技术债务论证水平的健康经济学迁移要点包括：将整个资产组合表述为一份负担清单（DALY式——健康工程年究竟损失在哪里？）；诚实地以进展数学来论证偿还的正当性（通常是具有成本效果，而非直接节省成本）；按严重程度缺口为最糟糕系统的补救工作加权；并在提交大型补救提案时，附上一份能经受住规避的下游成本规则检验的冲抵分析——概率加权、已贴现、只计算一次。

陷阱

  • 只报告本金：一个吓人的大数字，若没有配套的利息估算，说明不了任何问题。
  • 将工具生成的债务数字奉为字面真理：SQALE统计的是规则违反次数；它遗漏了架构层面的债务（往往才是代价最高的那种），却计入了大量琐碎问题。
  • 零债务乌托邦主义：最优的债务水平并非零——债务本质上是一种杠杆；真正的问题在于利率高低。
  • "重写能一次性解决所有问题"：重写提案同样必须经受住同一套冲抵规则的检验——反事实成本、概率、贴现，一样都不能少。

来源