代码什么时候是“旧版”？[关闭]

我们都完成了，我们已经将一些代码（通常是我们继承的东西）标记为“旧版”？但是它仍然在生产系统中使用-真的是遗留的吗？什么使它成为遗产？我们应该回避这种毫无用处的代码吗？标签的纯粹意义在于让我们不断尝试新事物并保持高层管理人员的愉快和快乐？

答案摘要

通过回答，我看到了四个总体主题。这是我看到的细分：

1. 已交付的任何代码：6
2. 失效系统：2.5
3. 无单元测试：2
4. 开发人员不在周围：1.5

我本人比较喜欢Wikipedia的摘要：

遗留系统是继续使用的旧方法，技术，计算机系统或应用程序，通常是因为遗留系统仍然可以满足用户的需求，即使现在可以使用更新的技术或更有效的方法来执行任务。

其他人在答案中描述的很多内容都是代码成为“旧版”的原因。但是本质问题本身是这样的：

但是它仍然在生产系统中使用-真的是遗留的吗？什么使它成为遗产？

仍然在生产中使用它的事实正是使它成为传统的原因。如果该代码无法正常工作，或者不再在生产中使用，则该代码将分别“损坏”或“退役”。 旧版意味着它仍在使用并且可以正常工作，但是结合了不再使用的设计或技术。

您要么（a）想要升级/更新但不能或（b）仍在升级过程中的任何代码或系统都是旧系统。这并不意味着重构或常规代码清除，而是意味着可能需要使用新框架甚至新平台对设计进行重大更改。

系统或代码成为旧版的原因有很多：

• 缺乏定期维护或软件腐烂。显然，如果不定期维护应用程序，它将无法跟上软件领域的重大变化。这可能是由于简单的疏忽造成的，也可能是基于业务优先级或预算约束的故意选择。

• 缺乏测试。另一个答案引用了流行作者对测试未涵盖的任何代码都是传统代码的双曲线主张。这确实不是一个准确的定义，但这可能是根本原因。没有良好的测试（自动或手动），开发人员会胆怯，害怕做出重大更改，因为他们担心会破坏某些内容，从而导致上面的“软件腐烂”。

• 修订锁定，一个经常被忽视的因素，在使用大型开源库或框架的项目中尤其隐蔽（尽管我也看到它在商业工具中也是如此）。通常，将对框架/库进行大量的自定义，从而使升级非常困难或昂贵。因此，该系统成为旧版，因为它在较旧的（并且可能不再受支持）平台上运行。

• 源代码不再可用，这意味着只能将其添加到系统，而不能更改。由于必须对这些系统进行重写以进行升级（而不是进行增量/迭代修订），因此许多公司都不会打扰。

任何减慢或停止对代码库更新的操作都可能导致该代码库成为旧版。

现在，单独的，未声明但隐含的问题是，旧代码有什么问题？ 它通常被用作贬义词，因此出现了一个问题：

我们是否应该回避这种功能正常的代码的不必要的标签？

答案是否定的，我们不应该；标签是有保证的，该术语本身明确包含功能代码。关键不在于它的功能，但如何它的运作。

在某些情况下，遗留代码没有错。这不是一个坏词。旧版代码/系统不是邪恶的。他们刚刚收集了一些灰尘-有时很少，有时很多。

传统成为过时的时候，系统可以不再担任（全部）的客户的需求。 该标签是我们需要注意的标签。否则，它只是成本/收益方程式；如果升级成本低于其收益成本（包括较低的未来维护成本），则进行升级，否则，请不要理会。无需像通常为“税收审计”保留的那样吐出“遗留”一词。完全可以的。

通常，这意味着它是用某种语言编写的，或者是基于您通常不会在其中进行新开发的系统编写的。

例如，大多数地方都不在Cobol中编写新程序。但是，他们的大部分业务可能都在以Cobol编写的应用程序上运行。因此，这些应用程序被标记为“旧版”。

旧版意味着您宁愿替换而不是使用的任何代码。考虑到大多数程序员对大多数现有代码的态度，通常包括几乎所有内容，除了您当前正在积极编写的内容（在一个大型项目中，您必须对冻结的设计进行编码，甚至是您正在编写的内容）。时刻也可以包括在内）。

1. 强调“相对”旨在传达旧代码，即使您不愿意使用它，也意味着您被卡住了。我不确定重点是否足够。原因可能会有所不同。有些确实太大而无法替换。其他是与其他系统的接口。还有一些人则受到政治和个性的驱使（例如，代码太可怕了，但展位宝贝真是太神奇了）。
2. 我可能没有足够强调的另一点是，尽管代码质量可能是一个因素，但它很少（如果有的话）是唯一因素，而且通常甚至不是一个特别重要的因素。
3. 我认为推动单元测试的人是唯一的决定性因素，就像那个在路灯下寻找耳环的妻子丢下一个街区的家伙一样。光线可能会更好，但您仍在寻找错误的位置。喝库尔援助之前先想想。
4. （对3的推论。）在我看来，有些人在谈论他们对事物的期望而不是真实的样子。如果约翰·康威斯（John Conways）的Apple IIc Plus 人生游戏不是旧版游戏，那是因为它足够小巧，简单，可以很容易地重新实现。有史以来最完美的单元测试不会改变一个IOTA。

最后一点确实导致了我认为通常是正确的另外两点。

首先，即使实际上不应该将代码保留为旧版。高级别的经理通常认为重新实施系统将花费与最初实施相同或更多的费用，这很少是事实。

其次，单元测试是一把两刃剑。他们太容易想到实施中的本地化更改才是真正重要的。为了对大型系统进行重大改进，您经常（通常是？）必须对整体设计进行足够的更改，以使许多（如果不是大多数）单元测试变得无关紧要。不幸的是，单元测试的存在以及他们所采取的态度会使忽略实际必要的更改变得太容易了。

也许有一个例子会有所帮助：假设一个程序具有一个经过很好的单元测试的UI库，以及几个使用该库的程序。高层管理人员开始相信“启用网络”非常重要（并且仅出于争论的目的，让我们假设在这种情况下，他实际上是正确的）。经过仔细审查，中层管理人员发现他们当前的单元测试已经足够，他们可以从通过本地操作系统的窗口功能显示的用户界面更改为通过HTML / CSS / AJAX远程显示，同时保留所有原始输入验证。

很好，不是吗？它显示了单元测试有多有用。我们已经换掉了整个UI的整个实现，但是确保外观，感觉和功能几乎保持一致，并且所有用户输入都经过验证以确保数据完整性。单元测试挽救了一天！

或不！强大，高度灵活，经过仔细测试的用户界面库，使所有参与其中的人都看不到这样的事实，即对于市场上带有用户的该程序，基于Web的用户界面完全是错误的。真正需要的是具有RESTful接口的Web服务，并且绝对没有自己的UI。

现在，可以肯定的是，单元测试并不会消除人们理解其市场或意识到其真正需要的能力。同时，关于锤子和钉子的旧思路几乎浮现在脑海。如果您不仅有一把锤子，而且对这把锤子有很多经验，并且知道这是一种真正高质量的锤子，它在许多不同情况下都表现得非常好，那就更糟了。事实上，它在很多情况下能胜任许多事情，这使得当它完全是手头工作的错误工具时，甚至变得更加难以识别。

旧版代码通常以某种方式孤立。首席开发人员是唯一一个了解这一点的人，他被公共汽车撞了，他的笔记用他的母语乌克兰方言写成，如今该方言已成为一种死语。或者，也可以使用Visual Basic 6.0编写的任何内容。

我一直在研究遗留代码。我要说的特征是：

• 没有大量的努力就无法扩展
• 无法轻易将其迁移到新硬件
• 这对业务至关重要，无法轻松更换

如果没有这些特征，则可能不是遗留问题。如果您不喜欢前辈的Perl脚本，我会同情，但是我认为这不是遗留问题。我最近对一些已有15年历史的Perl脚本进行了现代化处理，该脚本已被连接到一个过时的Sybase数据库中。与对我们令人敬畏的COBOL会计系统进行甚至最小的更改相比，这简直是小菜一碟。

在迈克尔·费瑟斯（Michael Feathers）的书《有效地使用遗留代码》中，将遗留代码定义为单元测试未涵盖的代码。这是一个定义，我同意。我还认为旧版代码已经过时，但仍然可以使用。

从技术上讲，遗留是任何可以立即编写的代码。因此，一旦投入生产，这就是遗产。因为那里已经有价值，所以不能将其扔掉……您必须处理它。

这是“在您的时间之前”，但“仍然让您头痛”。

遗留代码是仅保留在代码库中的代码，因为否则很多事情将停止工作。换句话说：唯一的原因是向后兼容。

您宁愿更改它甚至将其丢弃，但是您不能这样做，因为您将破坏所有依赖它的代码（这可能是您无法相应适应的代码）。因此，您必须保留它（有时甚至维护它），但是您希望不要针对它编写所有新代码。

一个示例是不推荐使用的库API。它们仍然存在，因此，如果有人更新该库，仍然可以构建其项目，但是它们被标记为已弃用，并且编译器应向您发出警告。

另一个示例是Microsoft为使程序运行而做出的所有怪异技巧，这些技巧是针对已完全弃用的OS版本编写的。其顶峰是：

我最初是从热门游戏《模拟城市》的一位开发人员那里听说的，他告诉我他的应用程序中存在一个严重的错误：它在释放内存后立即使用了内存，这是一个主要的禁止措施，在DOS上可以正常使用，但是在Windows中无法正常工作，因为释放的内存可能会立即被另一个正在运行的应用程序抢占。Windows团队的测试人员正在研究各种流行的应用程序，对其进行测试以确保它们可以正常工作，但是SimCity一直崩溃。他们向Windows开发人员报告了此问题，他们分解了SimCity，在调试器中逐步进行了调试，发现了错误，并添加了特殊代码来检查SimCity是否正在运行，如果确实运行，则以特殊模式运行内存分配器。释放内存后仍然可以使用内存。
-Joel谈软件

传统需要继承。旧版代码就是您从过去继承的代码。即使您以前亲自编写过，它也是传统代码！

所有其他考虑因素基本上都源于您并非专门为当前项目编写的事实。本身并不一定是一件坏事。

我的观点是，认为遗留代码取决于多个方面，而“传统”标签可能是特定于组织的。

如果运行的硬件/操作系统较旧，并且已被供应商停产，请执行1。

如果出于任何原因，尝试修复它而不是重写它是更多的工作，因为

• 原来的开发人员不见了
• 程序写得不好
• 可以在更新的平台上做得更好，但仍然对公司值得

这样做

• 原始来源不再可用和/或缺少片段

罢工2。

将多个组织合并为一个组织-罢工3-一方面可能会被标记为遗产。

是否有更好，更便宜的替代品作为第三方应用程序和/或服务出售-警示4。

该组织是否像医院或学区那样，在日常运营中，一致性要比新技术重要？与商业/竞争性组织中的同一应用程序相比，将某个应用程序视为旧应用程序需要更长的时间。

如果该公司是一家小型开发公司，并且一直在增强/支持应用程序以执行客户所需的工作，那么它被视为旧代码还是“旧”代码。我知道一家名为Mc2Ok的公司-他们在似乎是Windows 3.1的情况下开发了该软件，并且一直在不断发展。它仍然具有Windows 3.1的外观，但是他们也为其添加了Web界面。这是一家由两人组成的开发公司（我猜是这样），我会说，当他们停止工作时，它将被视为遗产，如果使用它，则需要一两年的时间来迁移。但这可能还要再十年或更长时间。

有时，当管理发生变化时，它可能会一波又一波地变化，从而产生许多trick滴的影响...根据新管理的影响力，它可以使许多应用程序具有传统，否则可能会很好。

我认为，每个组织都必须定义“传统代码”对他们意味着什么。我过去经常每周浏览《星期日泰晤士报》的分类信息，以了解组织在寻找什么。那曾经是我不再需要的（也就是传统）的晴雨表。好了，《星期日泰晤士报》不再相关了：-)我们可以概括地说，COBOL是旧版，ASP Classic是旧版，等等...但是我相信每个组织都必须决定何时将应用程序视为旧版。

当人们害怕更改代码时，代码就是遗留的，因为他可能会破坏它。当整个系统可能因更改该代码而受苦时，会更加痛苦。

这就是为什么我也同意迈克尔·费瑟斯的定义的原因。具有良好单元测试的代码可以毫不费力地进行更改。

我还认为，遗留代码与它的年代无关。您可以从一开始就编写遗留代码。