前面我们提到了，面对软件工业时代的到来，我们的软件企业陷入了一种更深的迷茫之中，一种“后有追兵，前有悬崖，进退两难”的境地。后有追兵：面对维护了数十年之久的大型遗留系统，我们到底改还是不改？不改，面对越来越多的需求变更，我们维护的成本越来越高，变更变得越来越困难；面对不断涌现的新技术，使我们的系统显得越来越丑陋与落后；面对越来越多的竞争者，使我们面临着被市场淘汰的风险。前有悬崖：原本运行得好好的软件系统，凑合一下还可以运行几年。一不小心改出问题了，企业立马就歇菜儿了，面对大量的用户投诉，企业四处救火，竞争对手趁火打劫，这是任何软件企业都不能承受的巨大风险。难倒真的“熊掌和鱼不能兼得”吗？真的没有一种方法，能够既保证我们系统可以技术改造，又能有效地避免改造过程的风险吗？有，那就是系统重构。
提到重构，许多人都讳莫如深、敬而远之。什么是系统重构呢？大家可能有很多的不同看法：
1. 系统重构是那些系统架构师、技术大牛玩的高端玩意儿，咱普通屌丝不懂，跟咱没啥关系。
2. 系统重构就是改代码，大改特改那种，整个重来一遍那种，这个比较邪恶，比较容易改出事儿，还是不要轻易尝试为妙。
3. 我知道系统重构，也知道它能改善遗留系统，但我还是不敢轻易尝试，因为改出问题来怎么办，还是算了吧。
然而我认为，现在我们对系统重构有太多的误解，以至于我们还不怎么了解它，就已经将它拒之门外。什么是系统重构呢？它是一套严谨而安全的过程方法，它通过一系列行之有效的方法与措施，保证软件在优化的同时，不会引入新的BUG，保证软件改造的质量。这一点在我后面一步一步的拆解中，你可以慢慢体会到。
我们先看看系统重构的概念。系统重构，就是在不改变软件外部行为的基础上，改变软件内部的结构，使其更加易于阅读、易于维护和易于变更[1]。
系统重构中一个非常关键的前提就是“不改变软件外部行为”，这个前提非常重要，它保证了我们在改造原有系统的同时，不会为原系统带来新的BUG，以确保改造的安全。这里，什么是“为原系统带来新的BUG”？我们必须为其做出一个严格的定义，那就是“改变了软件原有的外部行为”。也许你对此有些不太赞同，改变了软件原有的外部行为，怎么就能武断地认为，是为原系统带来了新的BUG呢？为此我们来举个例吧。
假如一个系统的报表查询功能，原来在表格里的返回结果中，日期是这样表示的“2013-2-18”，经过系统改造以后变成这样了“2013-2-18 00:00:00”，这是BUG吗？作为开发人员你可能认为这算什么BUG，但作为客户那就是BUG，因为它让表格变得难看，使用不再方便了。系统重构，对于客户来说应当是完全透明的。我们为之做了很多工作，而他们应当完全感觉不到它的存在。如果我们的重构做到了这一点，那么我们的重构就必然是安全的、可靠的、没有风险的。
更广泛一些来说，如果我们打开软件内部，保证系统中的每个接口与改造前是等价的，也就是说，其输入输出在改造前后都是一致的。当我们的每个改造都是这样进行的，则必然不会为系统带来新的BUG。这就是我们进行改造的保险索，它也是我现在所说的重构，与以往那种拿着代码一阵瞎改的根本区别。
总而言之，系统重构不是那种冒着极大风险进行的代码修改，而是必须保证修改前后输入输出的一致，这就是我们说的“不改变外部行为”。为此，贯穿整个重构过程的是不断的测试。起初这种测试是手工测试，随后逐渐转变为自动化测试。每修改一点点就进行一个测试，再修改一点点。测试，就是系统重构的保险索。
[1] Refactoring: a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. ——引自《重构：改善既有代码的设计》
大话重构连载首页：http://www.cnblogs.com/mooodo/p/talkAboutRefactoringHome.html
特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！