Adrian Sutton
2025年8月
技术债已经成为工程挑战的一个常用术语，经常被认为是阻碍因素，但没有明确说明它的实际影响。 对于构建大规模关键基础设施的团队来说，这种模糊的框架无法捕捉到不同形式的债务以细微的方式影响我们有效交付价值的能力。
在OP Labs，我们发现，从对“技术债”的泛泛抱怨转变为识别具体的业务成本，可以产生更富有成效的对话。 当我们可以量化特定的实现选择如何降低开发速度、增加错误率或消耗维护资源时，我们就可以在产品和工程团队中做出更好的优先级排序决策。
这种精确性很重要，因为并非所有的技术债都具有相同的成本。 一些代表了经过计算的权衡，使我们能够更早地发布重要的功能，而另一些则在没有提供相应价值的情况下默默地消耗资源。 这种区别影响了我们沟通这些挑战的方式以及我们解决这些挑战的方式。
本文探讨了我们遇到的不同类别的技术债，它们对开发速度的各种影响，以及负责任地管理它们的策略。 通过理解这些模式，我们可以做出更明智的决策，从而最大限度地提高我们更快、更好地交付软件的能力，同时保持用户期望的可靠性。
意外的复杂性
每个系统都包含本质的复杂性——我们正在解决的问题的内在难度。 在OP Labs，这包括密码学和高级数学，这些支持了我们的业务价值。 然而，意外的复杂性经常伴随而来。
意外的复杂性使我们的系统更难于推理、测试和修改。 当代码变得不必要地复杂时，我们的开发速度会降低，而错误率会增加。 这会带来具体的业务成本：更长的开发周期、更多的资源用于修复，以及可能需要紧急响应的事故。
在解决意外的复杂性时，我们应该抵制完全重写的诱惑。 现有的代码体现了来之不易的经验，这些经验可能会在重写中丢失，而重写本身也会通过阻止进度而成为技术债的形式。 增量简化，虽然在时间上有时会慢一些，但风险较低，并允许我们继续并行交付价值。
例行和延迟维护
例行维护——更新依赖项、合并上游更改、测试备份——对于防止代码腐烂是必要的。 我们可以通过自动化和工具投资来降低这些成本，正如我们通过op-workbench等项目成功实现的那样。
推迟维护会产生经过计算的风险。 虽然它可能在短期内释放资源，但延迟的成本可能会成倍增加。 例如，当我们推迟扩展Cannon以支持Go 1.23时，我们在合并上游更改方面经历了级联延迟，并且面临更大、风险更高的审查。
这类似于推迟汽车维护——跳过更换机油可能行得通，但可能会导致更昂贵的发动机故障。 避免中断当前工作的短期延期是合理的； 较长的延期通常会成为虚假的经济行为。
糟糕的可用性作为技术债
有时，我们标记为“技术债”的东西代表了限制功能或修饰以满足交付截止日期的有意决策。 这会产生持续的成本，尤其是在我们使用自己的软件时。 一个主要的例子是我们无法部署具有正确配置的无需许可的故障证明的新链——范围缩小帮助我们更早地交付，但现在在创建devnet时花费了大量时间。
虽然完美的可用性可能会延迟交付，但糟糕的可用性的累积成本最终会超过最初解决它的成本。 这些决策需要仔细的产品考虑，权衡短期交付需求与长期效率。 我们需要清楚地沟通这些权衡的业务影响，以做出明智的优先级排序决策。
错误和事故响应
修复错误和响应事故的直接成本是显而易见的，但却是巨大的。 更重要的是，它们代表了对计划工作的中断，扰乱了流程并延迟了价值交付。
对测试（尤其是在开发早期）、监控和事故响应工具的投资可以显著降低这些成本。 我们应该跟踪警报模式并为可靠性改进分配容量，并期望随叫随到的工程师能够解决警报的根本原因，而不仅仅是响应症状。
无效代码
功能开关、已弃用的功能和未使用的功能会累积为“无效代码”，这些代码不提供任何价值，但仍需要维护。 这包括围绕已发布但从未获得吸引力的功能配置的复杂性。
我们需要规范的流程来在部署稳定后删除功能开关，并停止使用未能实现预期价值的功能。 与产品团队合作做出这些决策有助于防止为不再有益于业务的代码支付持续成本。
缺乏测试
没有足够自动化测试的代码代表了成本最高的技术债形式之一。 我们的推导管道就是这种挑战的例证——由于代码的共识关键性质，我们限制了审查员池，但是这种依赖于人的过程既低效又容易出错。
更全面的自动化测试将同时提高信心并扩大可以安全贡献的开发人员池。 最终，每个错误和事故都代表一个遗漏的测试，该测试本可以更早地发现问题。
缓慢的反馈循环
开发人员的生产力取决于快速的反馈。 开发人员等待了解其更改是否正确的时间越长，他们浪费在追求不正确路径上的时间就越多，修复的成本也就越高。
反馈循环涵盖从编译器运行时间到测试执行再到我们的整体开发过程的所有内容。 缩短这些循环——通过测试优化、以更小的增量工作以及在流程中更早地进行验证——是提高生产力的最有效方法。
结论
通过其特定的业务影响来理解技术债，可以更好地决策要解决什么以及何时解决。 通过比简单地“技术债”更精确地对问题进行分类，我们可以有效地沟通它们的成本并优先考虑可以最大限度地提高我们交付价值能力的解决方案。
目标不是消除所有的技术债——一些经过计算的权衡是必要的——而是充分了解其长期后果的情况下做出这些决策。 通过系统地解决最具影响力的技术债形式，我们可以在保持开发速度的同时构建保持可维护性、可靠性和适应不断变化的需求的系统。
在OP Labs，我们不断改进我们应对这些挑战的方法，在技术卓越与务实的交付之间取得平衡。 我们正在寻找与我们一样致力于可持续开发实践的工程师——他们可以识别何时快速解决方案有意义，以及何时对基础设施的投资会产生累积回报。 如果你热衷于构建可以随着时间推移优雅地发展的关键系统，我们很乐意收到你的来信。
