旧版代码

这是什么，我们可以做什么。

传统代码是大多数开发人员的祸根。 但这是我们所有人都必须面对的现实。

它是您从其他人那里继承的代码，也许是从较旧版本的应用程序继承而来的。 通常情况下，它没有任何适当的文档 ，很多气味以及，的感觉，“我们应该对此进行重做……但它仍然可以正常工作”。

我敢肯定，一些开发人员会将大部分时间都花在相对较新的代码库上，他们将从头开始构建代码库，并且他们永远不会这样处理遗留代码。

即使那样，我认为您也可以继承自己的遗产代码，或者更准确地说，继承自“ 5年前”。

我记得我曾经使用基于许多选项，参数和集合的看似构造很长字符串的代码。 然后，它评估了它。

当我去见构建该库的同事时，发现当时他们只是不知道您可以在Ruby中完成多少元编程而无需进行eval调用。

代码的其他一些部分是框架本身可以做的事情的直接重新实现。 “我们从8年前开始使用版本1点东西” –现在是4.2版。

我猜，时间使所有事物变得陌生。

我应该澄清一下，遗留代码本身并不是坏代码。 它只是旧的，或者比它应该复杂的多，而且找不到作者。

我讨厌

而且我认为这是我们最常用于遗留代码的方法。 我们倾向于核武器，将其全部重写，并诅咒那些在我们之前的人。

事实证明那不是很好。

缺乏预先编写的测试，缺乏对要重写的代码的全面了解，以及重构操作中结构不良，常常使我们产生一堆混乱的代码，这对我们来说似乎只比上一个更好，因为这是我们自己制作的。

我留下了很乱的代码。 然后，它变成了自己的旧代码。

那该怎么办？

事实证明，处理遗留代码并不是一清二楚。 这更像是改善环境。 每当您发现功能有所改进的部分时，便要逐一升级。

它正在为您必须在那个旧库上进行的修改编写一个测试，花了一段时间弄清楚了它们后，才对hackey代码进行注释，它用for或each替换了while循环。

旧版代码从来都不是业务优先事项。 试图使其成为一个实例通常会使它变成新的，即将成为旧版的遗留代码。 让我们在任务估计中考虑它，并尽一切可能做些什么。

From: https://hackernoon.com/legacy-code-40027792bf85