每个代码库都有技术债务。有些是显性的：已知但未修复的 bug、TODO 注释、临时的 workaround。有些是隐性的：过时的架构、缺乏测试、文档缺失。
很多人把技术债务当成代码质量问题。但从更深层次看，技术债务的本质是时间问题。
技术债务是时间的借贷
你为了快速交付，选择了一个不够完美的方案。这就像贷款：你现在拿到了钱（功能上线了），但未来要还利息（后续维护成本更高）。
适度的债务是合理的。创业公司需要快速验证市场，债务可以换取时间。但关键是：你要知道自己借了多少钱，利息有多高。
显性债务 vs 隐性债务
显性债务是你知道的。"这里代码有点乱，后面要重构"。"这个性能问题先记录下来，以后优化"。
因为你知道，所以可以管理。可以评估优先级，可以安排偿还计划。
隐性债务更危险。你以为没问题，但实际上是定时炸弹。没有测试的代码、过度耦合的模块、缺乏文档的复杂逻辑——这些都在累积利息。
最可怕的不是债务本身，而是你不知道自己有债务。
债务的复利效应
技术债务有复利。债务越多，新功能开发越慢。开发越慢，越没有时间重构。于是债务继续累积。
很多团队陷入这个恶性循环："现在太忙了，没时间重构。等忙完这段时间再说"。但"这段时间"永远不会结束。
偿还债务的时机
不要等到"有空了"再还债。要在每次改动相关代码时，顺手改进。
这就是"童子军规则"：离开营地时，要比你到达时更干净。
修 bug 时，优化周边代码。加功能时，重构依赖模块。review 时，提出改进建议。每次接触代码，都是还债的机会。
技术债务的度量
如果你不能度量它，就不能管理它。
简单的方法：代码复杂度分析、测试覆盖率、bug 密度、构建时间。这些指标可以帮你量化债务，做出数据驱动的决策。
更直接的方法：问问团队。"哪些代码最让你头疼？""哪些功能改动风险最高？"团队的直觉往往比指标更准确。
债务不总是坏事
不要把所有技术债务都当成坏事。有些债务是战略选择。
MVP 阶段的快速开发，用债务换取时间。探索期的技术选型，用债务保持灵活性。只要债务是可控的、有意识的，它就是工具，不是负担。
关键是要有清晰的认知：这不是最佳方案，但这是当前最优方案。
长期主义者的债务观
真正的长期主义者，不是零债务，而是可控债务。
他们会定期评估债务的健康度，合理安排偿还计划，在快速交付和代码质量之间找到平衡。
技术债务不可避免，但可以让它为你服务，而不是让你为它服务。
—— https://www.80aj.com