什么是代码遗留?

通过使用不再受支持或已被取代的硬件、软件、API、语言、技术或功能,通常结合很少或根本不可能替换该代码,而是使用它直到它或系统死亡。

是什么造就了代码,遗留代码?

与普通遗产一样,当作者死亡或失踪时,作为继承人,您可以获得他的全部或部分代码。

你流下了眼泪,想弄明白怎么处理这些垃圾。

Michael Feathers在他的书中有一个有趣的定义,即有效地使用遗留代码。根据他的说法,遗留代码是没有自动测试的代码。

这是一个非常普遍的(经常被滥用的术语),但以下任何一项都是称应用程序为遗留的合法理由:

2. (实际上是1a)构建该系统的代码库或平台非常陈旧,因此要为该系统找到合格或有经验的开发人员既困难又昂贵。

3. 该应用程序支持业务的某些方面,这些方面不再积极发展,而且很少发生变化,通常是在周围发生完全出乎意料的变化(典型的例子是Y2K问题)或某些监管/外部压力迫使其改变时修复。由于这两个原因都是紧迫的,通常是不可避免的,但在项目上没有发生重大进展,因此指派处理这一问题的人员很可能不熟悉该系统(以及其累积的行为和复杂性)。在这些情况下,这通常是增加与项目相关的感知和计划风险的原因。

4. 该系统已经/正在被另一个系统替换。因此,该系统可用于远低于最初预期的用途,或者可能仅作为查看历史数据的手段。

根据《卓越》一书的作者迈克尔·费瑟的说法 Working Effectively with Legacy Code

主要区别是什么 非遗留代码中的遗留代码是 你可以用一点时间来理解这一点 如果需要,请修改代码库 大型代码库是对 不经意地改变事情。具有 测试,你可以让事情变得更好 免于惩罚对我来说,差别太大了 关键的是,它压倒了任何其他 情况好转了。没有他们,你只是 不知道事情是否变得越来越糟

一位同事曾经告诉我,遗留代码是您自己没有编写过的任何代码。

可以说,它只是一个贬义词,用来指我们出于任何原因不再喜欢的代码(通常是因为它不酷也不时尚,但它很管用)。

TDD团队可能会建议,任何未经测试的代码都是遗留代码。

Legacy code 与不再支持或制造的操作系统或其他计算机技术相关的源代码。

1. 它是有价值的,如果不是有用的话,它早就被扔掉了
2. 这很难解释,因为我们两个
   1. 缺乏文件,
   3. 缺乏测试或打字系统
3. 需要对其进行更改或扩展。 如果不需要更改它,那么它就不是遗留代码

http://en.wikipedia.org/wiki/Legacy_code

“遗留代码是与不再支持或制造的源代码相关的源代码”

缺少支持(或文档)的任何代码。就这样吧:

• 内联注释
• 技术文件
• 口头文档(编写者)
• 记录代码工作的单元测试

对我来说,遗留代码是在某种范式转换之前编写的代码。 它可能仍在大量使用中,但正在进行重构以使其符合要求。

当代码(或其他任何东西)被更新/更好的东西所取代时,它就变成了“遗产”,尽管如此,它仍然在“野外”使用并保持活力。

保留遗留代码与其说是一种学术理想,不如说是保持代码正常工作,不管它有多糟糕。在许多保守的企业环境中,这被认为比扔掉它然后从头开始更实际。最好是你知道的魔鬼。。。

遗留代码是一种痛苦/昂贵的代码,无法跟上不断变化的需求。

有两种方法可以实现这一点:

2. 代码的语义已被替换为silicon

1) 两者中,最容易识别的一个。正是软件有着根本的局限性,使得它无法跟上周围的生态系统。例如,围绕O(n^2)算法构建的系统不会扩展到某个点之外,如果需求朝该方向移动,则必须重新编写。另一个例子是使用最新OS版本不支持的库的代码。

2) 很难识别,但所有这类代码都有一个共同的特点,即人们害怕更改它。这可能是因为它一开始编写/记录得很糟糕,因为它未经测试,或者因为它很重要,理解它的原始作者离开了团队。

构成活代码的ASCII/Unicode字符在与之相关的人们的心目中具有语义含义,“为什么”、“什么”以及某种程度上的“如何”。遗留代码要么是未拥有的,要么所有者没有与大部分代码相关的含义。一旦发生这种情况(如果代码编写得很糟糕,第二天就会发生这种情况),要更改此代码,必须有人学习并理解它。这个过程是编写它所需时间的一个重要组成部分。

你害怕重构代码的那一天,就是你的代码成为遗留代码的那一天。

• 它是用落后于当前标准一代人的语言或方法编写的
• 代码完全是一团糟,没有任何规划或设计
• 它是用过时的语言和过时的、非面向对象的风格编写的

与这里的其他一些观点不同,我已经看到很多现代应用程序在没有单元测试的情况下正常工作。单元测试还没有普及到每个人。也许十年后,下一代程序员将查看我们当前的应用程序,并把它们看作是不包含单元测试的“遗产”,就像我认为非面向对象的应用是遗留的一样。

如果只需对遗留代码库进行少量更改,那么最好保持原样,按照流程进行。如果应用程序需要剧烈的功能更改、GUI大修和/或找不到懂编程语言的人,那么是时候扔掉它重新开始了。然而,有一点需要提醒:从头开始重写可能非常耗时,而且很难知道您是否已经复制了所有功能。您可能希望为遗留应用程序和新应用程序编写测试用例和单元测试。

老实说,遗留代码是其他软件的任何代码、框架、api,它不再“酷”了。例如,COBOL被一致认为是遗产,而APL则不是。现在,我们还可以证明COBOL是传统的和APL,而不是因为它的安装基数是APL的100万倍。然而,如果你说你需要在APL代码上工作,那么答案将不是“哦,不,那些遗留的东西”,而是“哦,我的上帝,我猜你在下个世纪不会做任何事情”,看到区别了吗?

我喜欢把遗留代码看作是 . 这只是过去编写的代码。在大多数情况下,遗留代码不遵循新的/当前的实践,通常被认为是过时的。

遗留代码是一个多月前编写的任何代码:-)

很多代码不是用流行的脚本语言dujour编写的,我只是半开玩笑。