代码不是技术债

代码：资产、负债，还是两者兼有

• 许多人认为代码本质上是一种资产：它承载着能够产生商业价值的功能。
• 也有人坚持认为，把代码建模为负债更有用：每一行都会增加未来的维护成本和认知负担。
• 还有一些人试图调和这两种观点，认为功能才是资产；实现该功能的代码则是一种成本或负债，其代价甚至可能超过其价值。

“技术债”到底是什么意思

• 常见误用：“技术债” == “糟糕的代码”。多位评论者不喜欢这种混为一谈。
• 另一种表述：技术债是当前实现与如果今天在充分了解情况且没有时间压力下你会如何构建之间的差距。
• 还有一种看法：技术债是被推迟或走捷径的工作，用“延后工作”来描述更好，以避免对成本估算过于自信。
• 也有人认为“债务”这个比喻有缺陷：粗糙的代码更像是在摧毁当前价值，而不是承担一项义务。

指标、代码行数与复杂度

• 对用代码行数来衡量成本或价值的做法有强烈反对。
• 更多代码通常与更多 bug 和更高复杂度相关，但更少的行数如果晦涩或过度聪明，也可能更糟。
• 强调的是认知负担、清晰度和抽象质量，而不是原始规模。

何时重写或重构

• 完全重写被描述为高风险，且很少有充分理由；更推荐渐进式重构加上强测试。
• 有人认为，在测试很差的代码库里，“伟大的重写”会反复出现；而测试良好的系统更像资产，也能更安全地演进。

上下文：软件类型与团队规模

• 区分了相对稳定的系统工具和快速变化、需求不断调整、团队轮换频繁的业务软件。
• 在单人、低变化领域里感觉“没有技术债”的情况，往往并不能推广到大型、持续演化的产品。

会计与房地产类比

• 多次拿房屋、工厂和房地产作比较：它们是有持续维护和折旧的资产。
• 具有会计思维的评论者强调：代码是资产；相关的维护和捷径是负债，而不一定是“债务”。

其他观点与元讨论

• 用来思考价值与维护之间关系的比喻还包括花园、厨房电器、飞机（重量）、牙齿和脚手架。
• 有人认为“技术债”这个术语已经变得过于泛化，以至于它带来的遮蔽多于澄清。