所有代码都是技术债
将“所有代码都是技术债”作为框架引发争论：这一术语是否已被扩展到失去效用，还是有助于强调每增加一个功能和每写一行代码都会带来持续成本。评论者重新审视 Ward Cunningham 原本的债务隐喻，将其与现代“取巧”解释对比，并认为代码更适合被看作负债、存货或折旧资产，其价值必须证明维护和复杂度成本是合理的。许多人强调，真正的杠杆来自更少且经过深思熟虑的功能、积极删除未使用代码，以及让业务相关方明确权衡速度、质量和长期灵活性。
“技术债”的范围
- 许多人认为这篇文章把“技术债”稀释了，因为它把所有代码都称为债务；他们认为技术债是特定的取巧做法或不匹配的设计，会在未来工作中产生“利息”。
- 也有人把它扩展得更宽：任何当前代码与当前理解/需求之间的不匹配，或者更一般地说，任何你想对系统做的事情与系统实际状态之间的阻碍。
- 对其原始含义（由学习驱动的设计滞后）与现代“我们明知故犯地偷工减料”用法之间也存在争论；有些人遗憾“技术债”和“重构”等精确术语已经变得模糊。
代码作为负债、资产或存货
- 一个强烈主题是：代码是一种负债/持有成本。代码越多 → 需要理解、维护和适配的东西越多；删除代码会被视为值得庆祝。
- 反方观点：可运行的软件和有用的功能是资产；代码至少在某种程度上是资产，因为它使变更和创造价值成为可能。
- 有些人更喜欢“存货”或“折旧资产”之类的比喻，而不是“债务”或“纯负债”。
复杂性、功能与假设
- 更多的功能和假设会增加复杂性和未来摩擦，即使它们今天“能用”。
- 多位评论指出，大多数项目并没有删除足够多的代码或功能；过时或未使用的代码持续存在，累积隐性成本。
- 一个反复出现的观点是：好的工程是尽量减少假设和概念，并在可能时尽量在现有假设内工作。
质量、熵与维护
- 许多人把技术债看作一种熵：即便是出于良好意图的决策，也会随着需求、平台和人员变化而累积成复杂性。
- 有人区分“糟糕的编程”和“好代码”：后者只是反映了过时的理解或需求。
- 测试和抽象也有成本；过度抽象（例如把 DRY 用得太过头）可能比重复更糟。
组织与沟通问题
- 商业相关方往往把“技术债”当作纯粹的技术麻烦；评论者强调要从上市时间、可靠性和机会成本来表述。
- 管理层激励更偏向增加功能并推迟清理；提出重构或重写很冒险，而且很容易招致责备。
对文章的反应
- 有些人觉得标题和前提像是在博点击，或过于简化；也有人欣赏它引发了对过度构建、功能膨胀以及少写代码价值的反思。