6. 重构之前

重构之前

        有些时候程序员需要重构已有的代码。但在重构前，请你思考下列各项，这样可以减少你和他人很多的时间（和痛苦）：
        重构最好的方法是从检查已有的代码库和针对代码的测试开始。这可以帮助理解当前代码的优点和缺点，确保在维持长处的同时避免错误。我们总觉得自己可以比当前系统做得更好......直到最终做出来的东西没有比以前的变得更好——甚至更差了，因为我们没有从已有系统的错误中学到教训。
        抵制重写一切的诱惑。尽可能多地重用代码。不管原来的代码多么丑陋，它都是已经测试过、评审过的。扔掉旧的代码——特别是以在产品中的——意味着你正在丢弃数月的（或者数年的）测试过的、久经考验的代码，他们可能包含你不知道的问题解决方法或者bug修正。如果你没顾及这些，写出来的新代码可能会出现本来已经在旧代码中修复了的诡异bug。这会浪费大量的时间、精力和多年积累的知识。
        为数众多的增量改变比一个巨大的改变要好。增量改变能让你通过反馈，比如来自测试的，更容易地精确估量其对系统的影响。当你做了一个改变后，看到了成百个的测试失败，你可高兴不起来。这会导致挫折和压力，最终做出错误的决定。一两个测试失败是很容易处理的，也提供了更容易掌控的途径。
        每一个迭代后，确保已有的测试能通过是很重要的。如果现有的测试不能充分覆盖你所做的改变，则要增加新的测试。不要未经考虑就把旧代码的测试丢弃。表面上这些测试可能看起来不适用你的新设计，但是深挖一下以前增加这个测试的原因，还是非常值得的。
        不要把个人的喜好和自负弄进来。如过东西没坏，为什么要修理它呢？不要因代码的风格或结构不合你意而重构，也不要因为你觉得自己可以比以前的程序员做得更好。
        新技术不是重构的充分理由。要重构的最不合适的理由之一是，现有代码跟不上我们今天所有的很酷的技术了、相信一个新的语言或框架可以让它更加优雅。除非付出收益分析表明，新语言或框架可以在功能、可维护性或生产力上带来重大改进，否则就不要动它。
        记住人是会犯错误的。重构并不总是能保证新代码会更好，甚至只是要跟原先想的同样好。我曾经看见过、经历过几个失败的重构。它不漂亮，但是人为的。

原文：Before You Refactor byRajith Attapattu