> 在我的职业生涯中，我采用了一种特定的方法，即从零开始构建新系统……

我同意你的观点。太多开发者往往忘记客户只关注功能。干净的代码、单元测试、严格的过程……它们的价值仅在于它们能实现的功能速度。 复杂性和技术债务是我们的麻烦，而客户根本不在乎我们如何解决它，甚至是否解决。只要我们还在与一段破烂代码挣扎，那就对我们有利：这意味着产品在销售，维护它的努力仍然有意义！ 没有复杂性和技术债务的销售会更好，我想我们都会同意这一点，但这是我个人从未亲眼见证过的成功案例。

即使是有15年历史的遗留系统和数以万计的工时，也会被替换。这些项目并不总是成功，但我见过这种情况。 从头开始重写不需要与旧系统完全一致，只要你能事先发现、实现和测试所有关键的业务用例即可。 最后一部分也是大型系统替换项目失败、超预算或甚至不被尝试的最常见原因。 通常，掌控资金的人并不了解旧系统隐藏的复杂性。稳妥的选择是继续使用它。

当代码库需要以原始设计中未包含的方式进行扩展时，问题就会出现。你实际上必须在扩展的那一刻进行‘大规模重构’，就好像新需求在系统最初设计时就已经知道一样。否则，你会很快陷入复杂的混乱中。

什么看起来像是不可行的解决方案？文章没有描述作者的“特定方法”。 你截断了： > [...] 比听起来要困难得多——更多内容将在另一篇帖子中讨论。 截至2024年5月29日，我还没有在该博客中看到更新的帖子。

熵是软件复杂性的良好类比。它需要更多的能量来减少熵而不是增加它——这是理解自然中系统在没有外部干预的情况下倾向于向更大混乱演化的根本原因。因此，一个工程师可以对系统造成如此大的破坏，以至于几乎无法修复。 这似乎是问题的关键，而这是一个人员问题。

> 在我见过的大多数甚至所有现实情况中，这似乎是一个不可行的解决方案。尤其是当你有一个有15年历史的遗留系统，且投入了数千人年的努力时。 > 现在，“不要让它发展到那个地步”是一个常见的IT极客式回答，我经常看到这种回答，但这种想法似乎是一种适用于不到10%的软件开发的“从零开始”的创业思维。 我认为，经常发生的情况是，旧系统在复杂性重压下崩溃的表现是，一个“新秀”（创业公司等）最终会接管它。只要新东西只舍弃了很少有人关心的旧包袱，并增加了很多人关心的新功能，就有可能实现接管。

你所描述的很多内容听起来像是创新者困境。使遗留系统难以处理的一个原因是，所有东西都有其存在的理由，但往往这个理由只是为了满足一小部分客户。很容易看到一个组件并说，这个功能只有2%的客户使用，我们应该考虑删除它。但那2%的客户是公司的客户，如果你删除了它，他们会大发雷霆。因此系统中充满了各种特殊情况来处理利基客户使用案例，而这些都无法被删除。这就是初创公司出现并针对高价值的基本使用案例，同时删除大部分高级功能的时候。然后他们开始吸引越来越多的客户，复杂性逐渐增加以满足他们的需求，最终初创公司变成了遗留公司，而这个循环又会重复。 作为开发人员的问题是，…

当我读到那个结论时，我真的笑出声了。这不仅听起来不可行且不可持续，还显得有点傲慢，很可能让与他们合作的其他人感到烦人。