技术债的发现、管理与偿还流程

技术债的处理分发现、管理、偿还三个环节。发现环节，代码类型的技术债（代码债、设计债）可以通过一系列危险信号识别：系统加载时间变长、特定模块缺陷率不断增加、同一问题在不同模块反复出现、增加新功能时新Bug数量持续增加、修复Bug时间变长、某模块难以被团队理解或测试、某模块源代码被频繁修改——这些信号本质上是把”这个模块是不是欠了技术债”这个难以直接判断的问题，转译成了一组可观测的工程指标。非代码类型的技术债（测试债、文档债）则更多依赖提高开发测试人员的基本技能素质和规范性，让每个环节都做到精确清晰完整可追溯来及时发现。管理环节需要关注一套要点框架（识别产生点、代价评估、利息评估、利息不确定性评估、技术债影响评估、自动化评估、专家意见、场景分析、市场投放时间、何时实现决定、实时跟踪、可视化技术债），书中特别指出这些要点对不同类型技术债的适用性并不均等：例如”技术债影响评估”涉及全部四种技术债，”识别产生技术债的点”对代码债、设计债、测试债的发现处理都很重要、但对文档债无能为力，”专家意见”这一要点则一般只适用于设计债的处理——这说明技术债管理不能套用一套统一的通用流程，必须针对每种技术债的特性挑选真正适用的管理要点；目前的技术很难完全自动化解决管理问题，需要自动化技术与人工管理相结合（如Sonar这类代码质量管理平台能通过插件集成测试分析工具、量化度量代码质量变化，帮助跟踪比较技术债，但同样无法覆盖所有技术债类型）。偿还环节遵循四步：发现项目中包含的技术债；把技术债加入产品列表中；根据债务影响和偿还成本进行优先级排序（这一步是针对整个业务需求做的，也就是要和非技术债的正常开发任务放在一起统一排序）；在合适的开发周期中修改偿还不同技术债——影响极小或修改代价太大以至超出收益的技术债，往往放在开发周期较后阶段偿还，以保证项目整体利益最大化；技术关键和架构技术债越晚修复代价越高，最佳情况是在最初技术选择和架构搭建时就尽量做到最优；对于即将退出市场或生命周期很短的产品，偿还其技术债反而不能带来整体利益、甚至不利于新产品推广，此时”不偿还、把精力投入新产品开发”才是最好的选择——这条例外说明技术债的偿还决策本质上是一个经济决策，而不是道德义务，判断标准始终是整体利益是否最大化。