技术债清还——我们如何边跑边修飞机

软件工程领域有一个著名的比喻：技术债就像信用卡债务。借一点可以加速前进，但利息会随时间累积。如果只借不还，终有一天利息会吞噬所有的新功能开发预算。

v1.0阶段，为了快速验证市场，我们做出了大量的技术妥协。当v1.0成功在市场中站稳脚跟时，我们面临的选择是：继续全力冲刺新功能，还是放慢脚步偿还债务？答案是两者都要——但需要一套系统的方法来平衡。这就是"边跑边修飞机"的由来。

技术债的分类框架：不是所有债都该还

还债的第一步是搞清楚欠了什么债。很多团队对技术债的理解停留在"代码写得不好"这个层面，这太粗糙了。我们将技术债分为四个维度：

架构债：系统设计层面的妥协。典型案例是v1.0的Agent调度器——所有Agent串行执行，当时为了快速上线选择了最简单的实现。当Agent数量从12增长到28时，这个架构债的"利息"变得极其昂贵——每增加一个Agent，响应时间呈线性增长。

代码债：具体实现的质量问题。重复代码、过长的函数、缺失的错误处理。这些单个看影响有限，但累积起来会显著降低开发效率。我们通过SonarQube扫描识别了超过200个代码债项。

测试债：缺少自动化测试或测试质量低。v1.0的测试覆盖率只有31%。这意味着任何修改都可能引入未知的Bug，团队对部署的恐惧与日俱增。测试债是最容易被忽视但利息最高的债务类型。

依赖债：过时的第三方库和不稳定的API版本。我们发现了17个存在已知安全漏洞的npm包和5个已停止维护的依赖项。

分类之后是优先级排序。我们使用了一个简单但有效的方法——将每项债务按"如果不还，半年后会多痛"进行1到5分评分。得分高的债优先还，得分低的可以慢慢来。这避免了"把所有代码重写一遍"的冲动——不是所有的不优雅都需要立即修复。

双轨开发模式：功能与还债的平衡术

我们采用"双轨开发模式"来平衡功能迭代和技术债清还。每个开发周期（两周），团队的时间分配遵循"70-20-10"原则。

70%的时间用于新功能开发。这是维持产品竞争力的基本投入。减少这个比例会损害增长，增加这个比例会加速债务积累。

20%的时间用于技术债清还。专门的技术债Sprint Backlog，从债务列表中按优先级选取。这20%是铁律——不能被新功能需求挤占。

10%的时间用于自由探索。开发者可以自主选择：修复一个困扰已久的Bug、尝试一个新的技术方案、学习一个相关工具。这10%看似是"浪费"，但实际上激发了大量优质的技术改进创意。

这个比例不是一成不变的。在产品重大发布前，我们会将新功能比例提升到85%，在发布稳定期将还债比例提升到30%。关键不是死守数字，而是始终保持对技术债的关注和投入，不让它从"待办项"变成"历史遗留问题"。

案例一：Agent调度器重构——最大的债，最痛的还

这是我们在v1.0到v2.0之间偿还的最大一笔技术债，耗时整整4人·月。v1.0的Agent调度器设计于产品早期，采用的是简单的链式调用：接收用户请求→调用Agent1→等待结果→调用Agent2→等待结果→...→汇总返回。

这个设计在Agent数量少、任务简单时运行良好。但问题随着产品增长迅速暴露：并行任务无法同时执行，单个Agent失败导致整个请求失败，新增Agent需要修改调度器核心代码，调试极其困难（哪个环节慢了无法定位）。

重构方案是联邦式事件驱动架构：每个Agent独立运行，通过事件总线通信，Supervisor从"指挥官"变为"协调员"。代码从最初的800行膨胀到重构后的3200行——但可维护性提升了不止一个数量级。

重构的代价是巨大的：4人·月可以开发10个中小型新功能。但如果不做这个重构，后续的所有Agent扩展和新功能开发都会因架构瓶颈而严重受阻。这是典型的高利息债——越晚还代价越大。

经验：架构层面的技术债，只要能承受，越早还越好。因为架构债的利息是复利——它会让每个新增功能的开发成本都额外增加。

案例二：测试覆盖率从31%到83%

v1.0时期，测试被认为是"有时间再做"的事。结果很自然——测试覆盖率只有31%，而且这31%中的大部分测试质量堪忧（Mock不完整，断言太宽松，测试间相互依赖）。

提升测试覆盖率的最大障碍不是技术，而是文化。当团队习惯了"开发完手动测一下就上线"，要求他们先写测试是巨大的习惯改变。我们采取了渐进式策略：

第一步：守住底线。所有新代码必须包含测试，覆盖率不低于80%。

第二步：补历史旧账。每周的20%技术债时间里，开发者为历史代码补充测试。按模块优先级逐步覆盖。

第三步：CI门禁。测试覆盖率下降超过1%自动阻断合并。这不是为了追求数字漂亮，而是确保"今天做的比昨天更好"。

六个月后，测试覆盖率从31%提升到了83%。更重要的是，团队的信心回来了——部署不再是一场豪赌。回归测试套件在10分钟内运行完毕，给出明确的通过/失败信号。

经验：测试覆盖率不是目的，团队对部署的信心才是。测试债清还的意义不在于数字，而在于让团队敢于快速迭代。

案例三：依赖项清理——看不见的定时炸弹

Node.js项目的node_modules是一个魔法黑洞——数千个包，数十万行代码，大部分开发者只知其名不知其内容。v1.0上线一年后，我们运行安全扫描，发现了17个含已知漏洞的包，其中4个是高危漏洞。

依赖清还的工作比预想的复杂。有些包升级需要API迁移，有些包已经废弃需要找替代品，有些包的漏洞实际上无法被利用但安全扫描仍然报警。我们花了3周时间逐项处理：升级了12个包，替换了3个废弃包，对2个误报进行了风险评估和抑制。

为了防止问题复发，我们将依赖项安全检查集成到CI流水线中。每次Pull Request自动运行npm audit，有高危漏洞则阻断合并。同时建立了依赖项月度审查机制，检查每个依赖项的必要性——不是每次加新功能都要引入新依赖。

经验：每一个新增的依赖项都是一笔潜在的技术债。在npm install之前，先问自己"不能用已有的依赖解决吗？"

维持技术健康：比还债更难的是不复债

清还技术债的最终目标不是"债清零"，而是建立一个"不累积新债"的机制。还款总有终点（当前版本的债还清），但如果不改变产生债务的习惯，新的债会继续累积。

我们建立了三个机制来防止债务复发：代码审查强制检查——任何引入新的已知反模式的PR必须附有ADR（架构决策记录）说明妥协的原因和计划偿还时间；技术债看板——所有已知债务可视化、可追踪、有人负责，而不是散落在开发者的记忆中；月度技术债评审会——回顾本月新增的债务，讨论是否需要调整策略。

边跑边修飞机是软件工程的常态。没有哪个团队可以不欠技术债——就像没有哪架飞机可以永远不用维修。关键在于：承认债务的存在，系统化地管理它，持续地偿还它，并建立防止债务失控的机制。这样，技术债就不是拖累你的负担，而是帮助你更快前进的工具。