代码没有下限：为何“沉船”比喻是错的
There's No Limit to How Bad Code Can Get
我在 Amazon 工作期间，曾深陷一个庞大而混乱的遗留系统。人们常把糟糕的代码库比作“沉船”，暗示它终会触底或沉没。但现实是，业务可能在代码彻底崩溃前就因成本过高而倒闭，而代码本身却能在抽象领域无限恶化。技术债务没有破产清算机制，也没有真正的重置按钮。只要没人主动舀水，这艘船就会永远下沉，且没有尽头。
软件处于抽象领域，不像建筑或桥梁那样受物理法则限制；如果你不断给大楼加楼层，它最终会坍塌，但软件没有这种约束，代码永远可以变得更糟，永远可以出现新的间接层或性能下降。
HN 评论区
79- ChrisMarshallNY
我第一份工作是维护工程师，负责一个 1979 年时代的 FORTRAN IV 代码库，规模超过 10 万行。
没有注释。
没有子程序（也就是我们现在说的“函数”）。
变量名长度不超过 4 个字符。
真“有趣”。当时最有效的调试工具是通灵板。这让我成了个 WAG（Wild Ass Guess，瞎猜）专家。
这也是我如今对代码质量如此较真的主要原因。我绝不想让任何人再经历那种折磨。
顺便一提：有了如今的 LLM，再没有理由写出文档糟糕或格式混乱的代码了。你可以写出一千行商业级的意大利面代码，然后让 LLM 去格式化并添加文档。
- blevinstein
> 技术债务没有破产，也没有清零重置的机会
技术债务绝对有“破产”选项。
你可以停止使用某段代码或某项技术，例如通过替换它（用新代码，或第三方/供应商方案），或者重构系统或业务流程，使得该代码的功能不再需要。
这正是技术债务这个比喻的含义。短生命周期的系统可以积累大量技术债务而无需过多担忧，因为你本来计划不久后就让它“破产”（弃用并退役）；而长生命周期的系统则必须计划按常规的分期方式偿还技术债务。
- lukasgelbmann
一篇很有见地的文章。作者关于组织内技术债务动态的一些观点非常精彩。
不过我认为“沉船”是个相当不错的比喻。船彻底沉没则是一个可怕、糟糕的结局。
在这个比喻中，当代码库变得无法继续使用时，它就“沉没”了。组织停止对其工作，也不再运行它。此时，这段代码对业务来说已完全毫无价值，就像沉在海底的船一样。诚然，理论上你可以想象代码会变得更糟。但在现实中，它只会坐在那里腐烂。[0] 业务可能会尝试重写，或者直接停止该产品。
业务有可能随着其中一个代码库的沉没而一同沉没，但这并非必然。如果业务高度依赖该代码库，船也可能因此沉没。
- socalgal2
两点看法
1. 根据我的经验，LLM 可以解决这个问题。LLM，尤其是较新的模型，其短期记忆能力远超大多数人类（至少比我强得多）。它们可以深入挖掘这类代码，理清所有边缘情况，编写测试，提出各种改进路径，然后执行这些路径。只要你需要，它们会乐意搭建开发环境、预发布环境，不惜一切代价确保过渡安全。至少这是我的经验。它们挖掘的深度远非我所能及。
2. 除了（或许独立于）LLM 的解决方案，我认为这种技术债务的模式几乎是不可避免的，至少在人类参与的情况下是这样。在理想世界中，每个人和每个审查者都确切知道该编写什么样的架构，该编写什么样的测试来传达所有规则和假设，因为无论如何，人总会离职。但我从未见过这样的代码库。因此，规则和假设充其量只写了一半，可能散落在某些注释或文档中，而这些注释或文档，下一个要修改该部分代码的人可能看到，也可能看不到。如此循环往复。
我工作的代码库运行在 Windows、Mac、Linux、Android 和 iOS 上。这些操作系统随时间推移而变化，它们的需求在变，API 在变，世界在变，人们的新需求需要新的 API，而我们最初为跨平台方案所做的选择已不再完美契合。我们必须不断前进、持续交付，不能停下来让世界静止然后重构。此外，正如楼主所说，并非每……
- cebert
如果你曾经和低成本的外包承包商合作过，你就知道这是真的……