我需要一些关于如何使用遗留代码的建议。
不久前，我接到的任务是向报告应用程序添加一些报告。 2005 年用 Struts 1 编写的。没什么大不了的，但是代码相当混乱。没有使用Action形式，基本上代码就是一个巨大的action，里面有很多if-else语句。此外，这里没有人具备这方面的功能知识。我们只是碰巧在合同中包含了它。
我对此很不满意，不知道如何继续。这个应用程序是隐形的：很少有人（但都非常重要）使用它，所以他们不在乎我在阅读代码、标准等时眼睛是否流血。
不过，我觉得技术债是要还的。我应该如何进行呢？继续沿着 if-else 的道路走下去，还是尝试以正确的方式满足此要求，而忽略项目的其余部分？冒着截止日期的风险开始大规模重构？
遗留代码是一个大问题，我相信人们不会同意！
我想说，开始大规模重构可能是一个错误。
重大重构意味着需要做大量工作才能使其按照现在的方式运行。如果您选择自己承担这件事，那么您所做的事情不会有太多的可见度。如果它有效，没有人会知道你写的工作时间。如果它不起作用，并且您最终得到了整洁的代码，但添加了一些错误（以及谁曾经编写过没有添加一些错误的代码），那么您将得到“为什么要进行此更改”类型的问题。
我目前即将完成一个基于 10 年历史的代码库的项目。一路上我们已经做了很多重构。但对于我们所做的每一次重构，我们都可以证明“这一特定的改变将使我们现在正在执行的实际任务变得更容易”。而不是“这对于未来的工作来说现在更干净”。我们发现，当我们处理代码、一次解决我们实际遇到的问题时，我们已经清理了很多代码，但没有（太多）破坏它。
我想说，在您进行大量重构之前，您将需要自动化测试，因此您会很高兴您已将其正确地重新组合在一起！
大多数重构都是为了“使维护和未来的开发更容易”。你的项目听起来未来不会有太多的发展。这限制了重构给公司带来的优势。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
