技术债务治理

债务是怎么越滚越大的

团队通常在两种时刻意识到技术债务的存在:某次上线前发现一半模块不敢动,或者新人对着一段没人敢删的代码问「这为什么能跑」。真正危险的不是坏代码本身,而是不可见的债务:没人记录、没人量化、没人排期。修复工作于是永远排在「更重要的功能需求」后面,直到重构窗口悄然关闭。

把债务变成可排序的清单

这个 Skill 把治理拆成四个可执行的动作:

• 识别:从常见代码坏味入手,例如重复逻辑、过长函数、紧耦合模块、缺失或过期的测试,用检查清单逐项对照。
• 量化:为每处债务评估影响面和修复成本,产出可比较的分数再排序,而不是凭直觉决定先改哪里。
• 偿还:采用 增量重构 路线,小步提交、持续验证,避免大爆炸式重写把风险集中到一次发布里。
• 预防:通过编码规范和质量门禁把新债拦在源头,防止「刚还完又欠下」。

使用时建议先明确目标与场景边界,再逐项执行或自查,最后输出结构化结果,包括清单、分级和后续建议,并标注不确定项,说明哪些环节需要人工复核。

适用边界

它提供的是方法论指导和清单参考,不会直连外部系统,也不负责实时数据采集。涉及业务权衡的债务决策仍需团队自己拍板,例如清理是否值得挤占当前交付节奏。法律、医疗、财税等需要持牌专业人士给出确定性结论的场景,不应依赖本 Skill。