关于使用遗留代码的建议 [英] Advice on working with legacy code

问题描述

我需要一些关于如何处理遗留代码的建议.

I need some advice on how to work with legacy code.

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

A while ago, I was given the task to add a few reports to a reporting app. written in Struts 1, back in 2005. No big deal, but the code is quite messy. No usage of Action forms, and basically the code is one huge action, and a lot of if-else statements inside. Also, no one here has functional knowledge on this. We just happened to have it in our contract.

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

I'm quite unhappy about this, and not sure how to proceed. This application is invisible: Few people (but all very important) use it, so they don't care whether my eyes bleed while reading the code, standards, etc.

但是，我觉得要偿还技术债务.我应该如何处理这个问题?继续沿着 if-else 的道路前进，还是尝试以正确的方式满足此要求，而忽略项目的其余部分?开始大规模重构，冒着最后期限的风险?

However, I feel that a technical debt is to be paid. How should I proceed on this? Continue down the if-else road, or try to do this requirement the right way, ignoring the rest of the project? Starting a huge refactor, risking my deadline?

推荐答案

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

Legacy code is a big issue, and I'm sure people will not agree!

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

I would say that starting a big re-factor could be a mistake.

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

A big re-factor means doing a lot of work to make it function exactly the way that it does now. If you choose to take this on on your own, there won't be a lot of visibility of what you are doing. If it works, no one will know the hours of work you put it. If it does NOT work, and you end up with tidy code, but add some bugs (and who has ever written code without adding some bugs) then you will get 'why did this change' type questions.

我目前几乎完成了一个使用 10 年历史代码库的项目.在此过程中，我们已经进行了相当多的重构.但是对于我们所做的每个重构，我们都可以证明这种特定的更改将使我们现在正在做的实际任务更容易".而不是这对于未来的工作来说现在更干净了".我们发现，当我们处理代码时，一次修复我们实际遇到的问题，我们已经清理了很多，没有破坏它(很多).

I have currently nearly completed a project working on a 10 year old code base. We have done quite a few bits of re-factoring along the way. But for each re-factor we have made we can justify 'this specific change will make the actual task we are doing now easier'. Rather than 'this is now cleaner for future work'. We have found that as we worked on the code, fixing the issues that we actually come up against one at a time, we have cleaned up a lot of it, without breaking it (much).

而且我想说，在您进行大量重构之前，您将需要自动化测试，因此您可以很高兴地将其重新组合在一起！

And I would say before you can re-factor much, you will need automated tests, so you can be fairly happy that you have put it back together right!

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

Most re-factoring is done to 'make maintenance and future development easier'. Your project sounds like there is not a lot of future development coming. That limits the advantage a re-factor will give the company.

这篇关于关于使用遗留代码的建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！