技术债常常被谈论得像是一种道德失败——一种让人应该感到羞愧的草率工作。这种定性是错误的，并且会导致糟糕的决策。债务是一种工具：有时为了赶上截止日期或验证一个想法，你会故意走捷径，这是一种理性的权衡。问题不在于承担债务，而在于盲目地承担债务且从不支付“利息”。目标不是零债务，而是受控的债务。
并非所有债务都是等同的
金融比喻确实很有用。有些债务是明智的低息贷款；有些则是扼杀你开发速度的高利贷。诚实地对其进行分类：
- 深思熟虑且谨慎的：“我们现在先硬编码实现，等到有第二个用例时再进行通用化处理。”没问题。
- 深思熟虑但鲁莽的：“我们没有时间测试任何内容。”很危险。
- 意外产生的：随着产品演进，才显现出错误的设计决策。这是不可避免且正常的。
重要的是利率——即某项债务每周在多大程度上拖慢你的进度。关键路径上的高息债务值得立即偿还；而在无人问津的稳定角落里的低息债务则可以长期存在。
使其可见
看不见的债务就无法管理。最常见的失败情况是，债务仅以模糊的恐惧形式存在于资深工程师的脑海中。相反，你应该：
- 记录下来。为已知的债务创建工单，并注明它造成的痛点及位置。
-
在代码中留下标记。使用一致的
// TODO\或// DEBT\约定，可以通过搜索将其转化为可检索的列表，从而将团队内部默契转化为显性知识。 - 关注信号。某个模块的错误率上升、交付速度变慢，或同一区域反复出现故障，都指向债务正在累积的地方。
让债务清晰可见，能将焦虑的走廊闲聊转化为一份可优先排序、可决策的清单。
持续偿还，而非一次性大规模重构
停止所有功能开发以进行“重构冲刺”的冲动几乎总是适得其反——业务方会对此不满，而大规模重写本身也伴随着风险。持续的、渐进式的偿还效果更好：
- 为每个周期预算一部分时间——例如 15% 到 20%——用于处理债务和维护。这具有可预测性和可持续性。
- 遵循童子军规则：每当因功能开发而接触代码时，都让代码比你发现时更整洁一点。
- 在你正在工作的地方偿还债务。重构你即将扩展的模块成本很低；重构一个随机且安静的模块则带有投机性。
这样可以在从不完全停止交付的情况下保持代码库的健康，而这正是关键所在。
与业务成果挂钩
“我们需要重构”之所以充耳不闻，是因为它被框定为工程卫生习惯。将其转化为利益相关者会采取行动的语言：这笔债务导致最近三个功能的开发时间都比预估多花了一周，或者这就是为什么我们每个周末都会收到报警电话。当你将债务与交付速度、可靠性和成本联系起来时，确定其优先级就不再是一场争斗。
平衡之道
管理技术债是一种持续的判断行为，而不是一个可以完成的一次性清理项目。要有意识地承担债务，公开追踪债务，在利息最高的地方偿还债务，并绝不让其变得不可见。做到这一点的团队既能快速交付，又能保持一个在一年后仍易于维护的代码库——你不必二选一。
如果你的交付速度正在放缓，且怀疑是债务所致，请联系我们。
最初发布于
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
