我听说许多开发人员将代码称为“遗留”。大多数情况下，代码是由不再从事该项目的人编写的。是什么造就了代码，遗留代码？
更新以回应：“从祖先或前任或过去传下来的东西” http://www.thefreedictionary.com/legacy。显然你想知道别的东西。您能否澄清或扩展您的问题？洛特
我正在寻找遗留代码的症状，这些症状使其无法使用或使用起来是一场噩梦。什么时候扔掉比较好？我认为应该更频繁地丢弃代码，并且重新发明轮子是开发的宝贵部分。不重新发明轮子的学术理想是一个不错的理想，但它不是很实用。
另一方面，显然有遗留代码值得保留。
通过使用不再支持或已被取代的硬件、软件、API、语言、技术或功能，通常几乎不可能替换该代码，而是使用它直到它或系统死机。
是什么造就了代码，遗留代码？
与普通遗产一样，当作者去世或失踪时，您作为继承人可以获得他的全部或部分代码。
你流下了眼泪，并试图弄清楚如何处理所有这些垃圾。
Michael Feathers 在他的《有效地使用遗留代码》一书中有一个有趣的定义。根据他的说法，遗留代码是没有自动化测试的代码。
这是一个非常笼统的（并且经常被滥用的术语），但以下任何一项都是将应用程序称为旧版的正当理由：
代码库基于原始产品制造商完全不支持的语言/平台（通常说制造商已经停业）。
（真的 1a）构建它的代码库或平台太老了，以至于为系统找到合格或有经验的开发人员既困难又昂贵。
该应用程序支持业务的某些方面，这些方面不再积极发展，并且更改极为罕见，通常会在其周围发生完全意外的变化（典型示例是 Y2K 问题）或某些监管/外部压力时修复它它。由于这两个原因都很紧迫且通常是不可避免的，但该项目没有发生重大进展，因此分配处理此问题的人员很可能不熟悉该系统（以及它的累积行为和错综复杂）。在这些情况下，这通常是增加对与项目相关的风险的感知和计划的理由。
该系统已经/或正在被另一个系统替换。因此，该系统的用途可能远低于最初的预期，或者可能仅用作查看历史数据的一种方式。
Legacy 通常是指不再开发的代码——这意味着如果你使用它，你必须按照它的原始条款使用它——你不能只是编辑它来支持当今世界的样子。例如，遗留代码必须在今天可能不存在或不再受支持的硬件上运行。
根据 Michael Feathers，优秀的Working Effectively with Legacy Code的作者，遗留代码是没有测试的代码。当无法知道此代码更改时会发生什么中断时。
遗留代码与非遗留代码的主要区别在于测试，或者说缺乏测试。我们可以通过一个小小的思考实验来了解这一点：如果它可以反击，如果它可以告诉你什么时候犯了错误，那么修改你的代码库会有多容易？这很容易，不是吗？对大型代码库进行更改所涉及的大部分恐惧是害怕引入细微的错误。害怕不经意间改变事情。通过测试，您可以使事情变得更好而不受惩罚。对我来说，这种差异是如此重要，它压倒了任何其他的区别。通过测试，您可以使事情变得更好。没有他们，你只是不知道事情是变得更好还是更糟。
一位同事曾经告诉我，遗留代码是您自己没有编写的任何代码。
可以说，这只是对我们不再喜欢的代码的贬义词，无论出于何种原因（通常是因为它不酷或不时尚，但它确实有效）。
TDD 团队可能会建议任何未经测试的代码都是遗留代码。
遗留代码是与不再支持或制造的操作系统或其他计算机技术相关的源代码。
没有人会读这个，但我觉得其他答案不太正确：
http://en.wikipedia.org/wiki/Legacy_code
“遗留代码是与不再支持或制造的源代码”
缺少支持（或文档）的任何代码。就这样吧：
对我来说，遗留代码是在某些范式转变之前编写的代码。它可能仍在使用中，但正在重构以使其符合要求。
例如，旧的程序代码挂在其他 OO 系统中。
当代码（或其他任何东西，真的）被更新/更好的东西取代时，它就变成了“遗产”，尽管如此，它仍然在“野外”使用并保持活力。
保留遗留代码与其说是学术上的理想，不如说是保持代码有效，无论多么糟糕。在许多保守的企业情况下，这被认为比扔掉它并从头开始更实用。最好是你认识的魔鬼……
遗留代码是为了适应不断变化的需求而痛苦/昂贵的代码。
发生这种情况有两种方式：
1）两者中较容易识别。它是具有基本限制的软件，使其无法跟上周围的生态系统。例如，围绕 O(n^2) 算法构建的系统不会超出某个点，如果需求朝那个方向移动，则必须重新编写。另一个示例是使用最新操作系统版本不支持的库的代码。
2) 更难识别，但所有此类代码都具有人们害怕更改它的特点。这可能是因为它一开始就编写/记录得很糟糕，因为它未经测试，或者因为它不是微不足道的，并且理解它的原始作者离开了团队。
组成活代码的 ASCII/Unicode 字符在与之相关的人们的头脑中具有语义含义，即“为什么”、“是什么”以及在某种程度上“如何”。遗留代码要么是无主的，要么所有者对大部分代码没有意义。一旦发生这种情况（如果代码写得非常糟糕，它可能会在第二天发生），要更改此代码，必须有人学习并理解它。这个过程是最初编写它所需时间的很大一部分。
你害怕重构代码的那一天，就是你的代码成为遗留问题的那一天。
如果以下任何或所有条件适用，我认为代码“遗留”：
与这里的其他一些观点不同，我见过很多现代应用程序在没有单元测试的情况下也能正常工作。单元测试仍然没有受到所有人的欢迎。也许十年后，下一代程序员会关注我们当前的应用程序，并认为它们是“遗留的”，因为它们不包含单元测试，就像我认为非面向对象的应用程序是遗留的一样。
如果需要对遗留代码库进行少量更改，最好保持原样并顺其自然。如果应用程序需要大刀阔斧的功能更改、GUI 大修和/或您找不到任何了解编程语言的人，那么是时候扔掉并重新开始了。但是，请注意：从头开始重写可能非常耗时，并且很难知道您是否复制了所有功能。您可能希望为旧应用程序和新应用程序编写测试用例和单元测试。
老实说，遗留代码是其他软件构造的任何代码、框架、api，不再“酷”了。例如 COBOL 被一致认为是遗留的，而 APL 不是。现在，人们还可以将 COBOL 视为传统和 APL，而不是因为它的安装基数是 APL 的大约 100 万倍。但是，如果您说您需要处理 APL 代码，则回复不会是“哦，不，那些遗留的东西”，而是“哦，我的上帝，你猜下个世纪你不会做任何事情”看到区别了吗？
这是软件生态系统中经常（并且非常笼统地）抛出的通用术语。
好吧，我喜欢将遗留代码视为继承代码。这只是过去编写的代码。在大多数情况下，遗留代码不遵循新的/当前的做法，通常被认为是过时的。
遗留代码是一个多月前编写的任何东西:-)
通常是任何不是用流行的脚本语言编写的代码，我只是在开玩笑。