怎样处理遗留代码
介绍
想象一下，你未来的工作是处理一堆遗留代码【注1】，它几经易手。你会发现好的或糟糕的代码、不同的代码风格、或多或少没有被单元测试覆盖到。到处都能嗅到代码的味道，或许还有严重影响效率、灵活性、易测试等等严重问题。然后，你心里可能产生了大量的优化代码的想法！好吧……不要碰它们！
为什么要保留现状？
请考虑以下因素：
-
它能运行。无论好坏，它运行好好的。虽说它可以运行地更好，但是你的时间有限，还有要实现的新功能，当然也有要修复的bug，更缺乏单元测试。或许，至少有一个通过测试了、并且是最重要的—时间的测试。除了这些以及效率因素，你可以辩解道：经过你的重构，代码会更加灵活、易于接手、新功能也会高效接入。的确如此。然而，你需要慎重。
-
你会引入新bug。修复遗留代码有点儿类似俄罗斯轮盘赌博，迟早你会引入影响到业务演示进度的新bug，也就没有人去在乎巨大的、却看不见的代码改进。你不能确定任何事情，这里有些例子。比如你看不到某些代码的说明，我们试着移除掉，然后检查一下，程序仍然能够运行。直到某一天你发现，环境之外的某些xml文件要用到那些很少用到却比较重要的场合才用到的代码，只是当时返回了空的、甚至更严重的异常，而该异常被一段空的catch块捕获了，导致你认为这些代码可以移除。你或许认为重新抛出而不是吞掉这些异常是个好主意？是的，不过你得到了很多来自程序深处的不太重要的异常，用户也得到了，是的，是你搞坏了程序，在你改代码之前程序是没有异常的。好吧，你至少加上一些异常捕捉方法。不，你没有时间，即使你有时间。
-
你做的小修改会引起雪崩式的其他变化。如果代码庞大而你是新手，你会发现有更多的依赖需要考虑。现在，你开始觉得向经理要的时间比你实际花费的时间要少很多（因为你不想让经理难堪），他给你的时间比你想要的以及解决问题真正需要的时间要少，你陷入困境了。
怎么办？
这是一个开放式的问题，取决于你面对的实际代码情况。我给出对我管用的方法：
...