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