有关使用遗留代码的建议

Question

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

不久前，我被赋予了向报告应用添加一些报告的任务。早在2005年就用Struts 1编写了。没什么大不了的，但是代码非常混乱。没有使用Action表单，基本上代码是一个巨大的动作，里面有很多if-else语句。此外，这里没有人具备这方面的功能知识。我们碰巧在我们的合同中有它。

我对此非常不满意，不知道如何继续。这个应用程序是看不见的：很少有人（但都非常重要）使用它，因此在阅读代码，标准等时，他们不关心我的眼睛是否流血。

但是，我觉得要支付技术债务。我该怎么办呢？继续沿着if-else道路行进，或者尝试以正确的方式执行此要求，忽略项目的其余部分？开始一个巨大的重构，冒着我的最后期限？

Answer 1

传统代码是个大问题，我相信人们不会同意！

我会说开始一个重要的因素可能是一个错误。

一个重要的因素意味着要做很多工作，使其完全按照现在的方式运作。如果您选择自己开启，那么您将无法看到自己正在做的事情。如果它有效，没有人会知道你把它的工作时间。如果它不起作用，并且你最终得到了整洁的代码，但是添加了一些错误（以及谁曾编写代码而没有添加一些错误）那么你将得到'为什么这个改变'类型的问题。

我目前几乎已经完成了一个有10年历史的代码库的项目。我们在此过程中做了不少重新分解。但是对于我们所做的每一个重新因素，我们可以证明“这个具体的变化将使我们现在正在做的实际任务更容易”。而不是“现在这对未来的工作更加清洁”。我们发现，当我们处理代码时，一次修复我们实际遇到的问题，我们已经清理了很多，而不是破坏它（很多）。

我会说，在您重新考虑很多因素之前，您需要进行自动化测试，因此您可以非常高兴您将它重新组合在一起！

大多数重新分解是为了“使维护和未来发展更容易”。你的项目听起来好像没有很多未来的发展。这限制了重复因素给公司带来的好处。

Answer 2

规则＃1：如果没有破坏，请不要修理它。

规则＃2：如有疑问，请重读规则＃1。

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

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

规则＃3：忽略我之前的段落并重读前两个规则。

Answer 3

我同意其他意见。如果你不必，那就不要这样做。如果代码库或多或少都死了，那么它的成本通常远高于它。

另一方面，如果您觉得无法理解代码，那么重构可能是不可避免的。如果是这种情况那么，既然它是一个Web应用程序，你能用硒创建一套可靠的功能测试吗？如果是这样，这对于这样的代码来说是最快和最有价值的测试方法，并且会捕获大部分错误。

其次，从提取方法重构开始，创建大难度方法的组合方法。每次你想到自己“这应该有一个评论来解释它的作用”你应该将它提取到一个名称替换评论的方法。

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

Answer 4

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

当它完成时，你很可能会更好地理解这段代码的作用以及它是如何工作的。

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

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

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

但不要从重构开始