refactoring - 关于使用遗留代码的建议

Question

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

不久前，我接到的任务是向报告应用程序添加一些报告。 2005 年用 Struts 1 编写的。没什么大不了的，但是代码相当困惑。没有使用Action形式，基本上代码就是一个巨大的action，里面有很多if-else语句。此外，这里没有人具备这方面的功能知识。我们只是碰巧在契约(Contract)中包含了它。

我对此很不满意，不知道如何继续。这个应用程序是隐形的:很少有人(但都非常重要)使用它，所以他们不在乎我在阅读代码、标准等时眼睛是否流血。

但是，我觉得技术债是要还的。我应该如何进行呢？继续沿着 if-else 的道路走下去，还是尝试以正确的方式满足此要求，而忽略项目的其余部分？冒着截止日期的风险开始大规模重构？

Answer 1

遗留代码是一个大问题，我确信人们不会同意!

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

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

我目前即将完成一个基于 10 年历史的代码库的项目。一路上我们已经做了很多重构。但对于我们所做的每一次重构，我们都可以证明“这一特定的改变将使我们现在正在执行的实际任务变得更容易”。而不是“这对于 future 的工作来说现在更干净”。我们发现，当我们处理代码、解决我们实际遇到的问题时，我们已经清理了很多代码，但没有破坏它(太多)。

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

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