糟糕的代码有多糟糕是没有限制的

糟糕的代码可以变得没有限制 TL;DR：像“一艘正在下沉的船”这样的比喻经常被用来描述代码库，但这是一种误导。在代码质量达到假设的最低水平之前，企业就会陷入困境。技术债务没有破产，没有干净的重置，因此暗示结束的隐喻提供了一种错误的安全感。软件属于抽象领域。它不像一座建筑物或一座桥梁，在物质领域中你可以看到并感受到事物的本质。如果你继续不断地增加建筑物的楼层和房间，它就会倒塌。软件没有这样的限制。代码总是会变得更糟。总是可能会出现新的间接层或性能下降。 1：登上一艘正在下沉的船 十多年前，我第一次遇到了丑陋的遗留代码库。我刚从大学毕业，作为“软件开发工程师”加入亚马逊，并在一个拥有与 .从表面上看，我们的代码要做的事情似乎很简单。处理订单涉及将一些内容写入数据库并调用其他团队拥有的服务，要么询问有效性问题，要么更新他们的簿记。我和我的同事估计，这个系统的充分实施不需要超过两打强大的工程师来维护和发展。然而，我们的组织有数百人，系统变得如此庞大和复杂，以至于不可能了解它是如何运作的。在这个组织中呆的时间很少超过几年，而且机构知识已经被侵蚀。这导致代码充满了 .恐惧抑制了任何简化现有系统的（回报不足的）努力。每种类型的订单必须执行的业务规则是很久以前由不再存在的人决定的。这些规则有时可以在一个无可救药地过时的文件中找到，该文件自豪地称自己为“动态文档”，但通常这些规则根本没有写在我们能找到的任何地方。自己跟踪行为也并不容易，因为系统的大部分内容都跨越团队边界，而代码不容易访问。当一些应该发生的订单没有发生一些模糊的过程时，我们的寻呼机会愤怒地通知我们，在我们错综复杂的服务依赖网络中有人不满意。由于这种反馈机制，系统保持运转，但仍然难以改变并且已经发生了。尽管如此，仍不断添加新层以支持最新的亚马逊产品和功能。这种感觉是不可持续的，正是这种感觉让我和其他人用“下沉的船”作为比喻来描述一个不偿还技术债务的组织。值得赞扬的是，总是需要修复架构，这些通常如下：新经理或高级工程师加入组织并观察到“事情很糟糕”。该组织的领导层同意并希望让事情变得更好，但没有可用的工程师，因此每次修复尝试都包括添加新工程师和。重新架构总是失败的：该系统需要多年的研究才能正确理解，并且不断变化。花这么长时间来设计系统修复方案在政治上是不可行的，因此自然每个试图修复问题的人都必须使用不完整的信息。这种不耐烦的部分原因来自于内部：如果您试图为如此令人痛苦的架构设计一个宏伟的修复方案，那么您这样做的部分原因是您想要晋升（并且您不想为晋升等待太久）。每个周期都会以新尝试的残余永久地嫁接到我们的架构上而结束，而领先的工程师则带着必要的晋升离开。增加的员工人数得以保留，因为迁移计划太痛苦且不受欢迎，无法真正完成。就像我到达之前很久一样。沉船似乎没有尽头。 2：到哪里结束？我离开大约三年后，我正在与该团队的一位前同事通过电话聊天。在经历了令人印象深刻的 6 年任期后，他最近离开了公司，并见证了这个周期的再次完成。我们都很同情，尽管我们已经分开好几年了，但我们都用沉船的比喻来形容这个组织。 “哪里结束？怎么结束？”他问我，很想听听我对该组织未来会发生什么的看法。这个问题和比喻不适合我，我意识到这个问题混淆了两件事。我们是在谈论代码，还是在谈论公司？企业可能会沉没。糟糕的软件确实会拖累业务，但其影响程度取决于很多因素。对于像亚马逊这样拥有充足现金流的公司来说，他们可以容忍偶尔出现一些内部腐败，然后再对其利润产生任何有意义的影响。对于另一家商业模式更敏感的公司