第1章重构改变既有代码的一剂良药.PDF

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