使用遗留代码的建议

Question

我需要一些关于如何使用遗留代码的建议。

不久前，我的任务是向报告应用程序添加一些报告。早在 2005 年用 Struts 1 编写的。没什么大不了的，但代码相当混乱。没有使用 Action 形式，基本上代码是一个巨大的 action，里面有很多 if-else 语句。此外，这里没有人对此具有功能性知识。我们只是碰巧在我们的合同中有它。

我对此很不满意，不知道该怎么做。这个应用程序是不可见的：很少有人（但都非常重要）使用它，所以他们不在乎我在阅读代码、标准等时是否会流血。

但是，我觉得需要偿还技术债务。我应该怎么做？继续 if-else 之路，还是尝试以正确的方式完成此要求，而忽略项目的其余部分？开始大规模重构，冒着最后期限的风险？

Answer 1

遗留代码是个大问题，我相信人们不会同意的！

我会说开始一个大的重构可能是一个错误。

一个大的重构意味着做大量的工作以使其完全按照现在的方式运行。如果您选择自己承担此责任，那么您所做的事情将不会有很多可见性。如果它有效，没有人会知道你投入了多少工作时间。如果它不起作用，并且您最终得到了整洁的代码，但添加了一些错误（以及谁曾经编写过代码而没有添加一些错误），那么您将得到“为什么要进行此更改”类型的问题。

我目前几乎完成了一个使用 10 年历史的代码库的项目。在此过程中，我们已经做了很多重构。但是对于我们所做的每一个重构因素，我们都可以证明“这种特定的变化将使我们现在正在做的实际任务变得更容易”。而不是“这对未来的工作来说现在更干净了”。我们发现，在编写代码时，我们一次解决实际遇到的问题，我们已经清理了很多，但没有（很多）破坏它。

我要说的是，在您进行大量重构之前，您将需要自动化测试，因此您会很高兴您已正确地将其重新组合在一起！

大多数重构都是为了“使维护和未来开发更容易”。你的项目听起来好像没有很多未来的发展。这限制了重构给公司带来的优势。

Answer 2

规则 #1：如果它没有损坏，请不要修复它。

规则 #2：如有疑问，请重新阅读规则 #1。

不幸的是，遗留代码很少被描述为“它没有损坏”。因此，我们必须调整现有代码以纠正新发现的错误，调整现有代码以修改以前可接受的行为，或调整现有代码以添加新功能。

我的经验告诉我，任何重构都必须以“无限小的”小增量进行。如果您必须打破规则 #2，我建议您从最内层的嵌套循环或 IF 结构开始搜索，然后向外扩展，直到找到一个干净的逻辑分隔点并创建一个新的函数/方法/子例程，其中仅包含该循环或结构的胆量。这不会使任何事情变得更有效，但它应该让您更清楚地了解底层逻辑和结构。一旦你有了几个新的、更小的函数/方法/子例程，你就可以将它们重构并整合成更易于管理的东西。

规则 #3：忽略我之前的段落并重新阅读前两条规则。

Answer 3

我同意其他 cmets。如果你不需要，那就不要这样做。如果代码库或多或少地死掉了，它的成本通常要高得多。

另一方面，如果您觉得无法完全理解代码，那么重构可能是不可避免的。如果是这样的话，既然它是一个 Web 应用程序，你能用 selenium 创建一套可靠的功能测试吗？如果是这样，这是此类代码的最快和最有价值的测试方法，并且可以捕获大多数错误。

其次，从 extract 方法重构开始，创建大困难方法的 compose 方法。每次你想自己“这应该有一个注释来解释它的作用”时，你应该将它提取到一个名称替换注释的方法中。

完成此操作后，如果您仍然无法添加所需的功能，您可以进行更高级的重构，甚至可能添加一些单元测试。但我通常发现我可以通过创建自文档代码来添加所需的内容/修复遗留代码中的错误。

Answer 4

简而言之：在对遗留代码进行任何修改之前，最好从自动化单元测试开始。 这将使开发人员了解关键内容：这段代码所具有的依赖关系、输入数据、输出结果、边界条件等。

完成后，您很可能会更好地理解这段代码的作用和工作原理。

在这之后，它是有意义的（但不是必须）清洁代码，为局部变量提供更准确的名称，将一些功能（重复代码，如果有的话）移到具有清晰人类友好名称的函数中。

简单的清理可以使代码更具可读性，同时通过单元测试帮助开发人员避免出现回归问题。

重构 - 逐步进行小改动，当您有时间并了解需求和功能时，定期对代码进行单元测试。

但不要从重构开始