技术债本质上是时间交换
为了赶上某个时间节点，选择一个实现更简单但不那么理想的方案，这是正常的工程决策。问题不在于是否欠债，而在于有没有人记得这笔债以及它的成本。
把技术债理解为纯粹的错误并不准确。在业务方向尚未验证时，快速上线本身就比结构优美更有价值。真正危险的是债欠下之后被遗忘，成本在暗处持续累积。
因此判断一笔技术债是否可接受，关键看它的利息有多高：是每次改动都要额外花半天处理，还是仅仅在阅读代码时不够舒服。前者需要尽快处理，后者可以长期存在。
区分主动负债与被动腐化
主动负债有明确的原因、范围和偿还计划。比如为了赶活动上线，某段逻辑先写死，约定活动结束后统一调整，这类债务在掌控之中。
被动腐化则没有决策过程。代码被不同的人以不同风格反复修改，命名逐渐失去含义，重复逻辑散落在多处，没人说得清某段代码为什么存在。这类问题不会自己好转，只会越来越难触碰。
两种情况需要不同的应对方式。主动负债靠计划偿还，被动腐化靠边界约束，比如约定新增功能不再继续扩散到某几个文件，或者要求修改时必须补充说明。
建立一份可以评估的债务清单
清单不需要面面俱到，但要能支撑决策。每条记录包含四类信息：位置、现象、影响、粗略的处理成本。现象要写成可以被验证的描述，而不是感觉不好这类判断。
影响部分最好与业务挂钩。比如导致新支付渠道接入需要两周而不是三天，或者每次调整报表口径都要人工核对一次数据，这类描述比代码质量问题更容易让非技术角色理解。
清单需要定期更新。修掉的划掉，新产生的补上，半年后就能看出哪些模块在持续产出新债务，那通常意味着该模块的边界设计有问题。
选择偿还窗口与偿还顺序
偿还技术债需要窗口。业务高峰期不适合做结构调整，容易引发线上问题且难以回滚；需求相对平稳的时期，或者在某个大功能上线之后，是比较合适的时机。
偿还顺序可以按两个维度排列：影响面与发生频率。影响面大且频繁拖慢工作的先处理，影响面大但很少触碰的次之，影响面小且很少触碰的可以长期搁置。
偿还时应当以行为不变为前提。结构整理与功能调整混在一起做，一旦出现问题很难判断原因，也会让回归测试的范围失控。把两者分开，风险会低很多。
另一个常见误区是把偿还技术债等同于追求代码美观。真正需要优先处理的是那些持续消耗沟通与时间成本的问题，比如同一份逻辑散落在多个位置、每次修改都要全部同步，或者缺少基本说明导致每个新成员都要重新摸索。相比结构是否优雅，这些因素对交付速度的影响更直接，也更容易被业务方感知。
