重构—改善既有代码的设计
原文链接：https://www.itsleuth.cn/archives/20180719142854
经典名言
- Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ——Martin Fowler
任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的代码。 ——Martin Fowler- I’m not a great programmer; I’m just a good programmer with great habits. ——Kent Beck
我不是个伟大的程序员，我只是一个有着一些优秀习惯的好程序员。 ——Kent Beck- Computer Science is the discipline that believes all problems can be solved with one more layer of indirection. ——Dennis DeBruler
计算机科学是这样一门科学：它相信所有问题都可以通过增加一个间接层来解决。——Dennis DeBruler
一、什么是重构？
所谓重构是这样一个过程：在不改变代码外在行为的前提下，对代码作出修改，以改进程序的内部结构。本质上说，重构就是在代码写好之后改进它的设计。
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
重构的目的是使软件更容易被理解和修改。重构不会改变软件可观察的行为——重构之后软件功能一如既往。
重构技术就是以微小的步伐修改程序，如果你犯下错误，很容易便可以发现它。
二、为何重构？
（1） 重构改进软件设计。 如果没有重构，程序的设计会逐渐腐败变质。重构很像是在整理代码，你所做的就是让所有东西回到应出的位置上。经常性的重构可以帮助维持自己该有的形态。
（2）重构使软件更容易理解。 “准确说出我所要的”，程序设计很大程度上就是与计算机交谈，但是除了计算机外，你的源码还有其它读者：几个月之后可能会有另一位程序员尝试读懂你的代码并做一些修改。我们很容易忘记这第二位读者，但他才是最重要的。计算机是否多花了几个小时来编译，又有什么关系呢？如果一个程序员花费一周的时间来修改某段代码，那才要命呢——如果他理解了你的代码，这个修改原本只需一个小时。
（3）重构帮助找到bug。 对代码进行重构，可以帮助我们深入理解代码的行为，并恰到好处的把新的理解反馈回去。搞清楚代码结构的同时，大胆假设、小心求证，想不把bug揪出来都难。重构能够帮我们更有效地写出健壮的代码。
（4）重构提高编程速度。 良好设计是维持软件开发速度的根本。如果没有好的设计，或许短时间内你的进度迅速，但恶劣的设计很快就会让你速度慢下来。你会花越来越多的时间去理解系统，寻找重复代码，调试代码。一个又一个的补丁堆下的技术债务让新特性需要更多代码才能实现甚至无法实现。而重构可以帮助我们更快速地开发软件，因为它阻止系统腐败变质，它甚至还可以提高设计质量。
三、何时重构？
重构不是一件应该特别拨出时间做的事情，重构应该随时随地进行。不应该为重构而重构，之所以重构，是因为我们想做别的什么事，而重构可以帮助我们把那些事做好。
三次法则：事不过三，三则重构。（第一次做某件事情时只管去做；第二次做类似的事情会产生反感；第三次再做类似的事，你就应该重构）
（1）添加功能时重构：添加新功能时通过重构理清原有代码；重构后的设计会让代码添加新的特性容易得多。
（2）修补错误时重构：调试代码查看错误的过程中运用重构，让代码更具可读性。
（3）复审代码时重构：改善代码开发状况，有助于较有经验的开发者把知识传递给比较欠缺经验的人，并帮助更多人理解大型软件系统中的更多部分。重构可以使我们获得更高层次的认识，发现代码中的缺陷。
四、何时不该重构？
* 现有代码代码根本不能正常运作*，你可能只是试着做点测试，然后发现代码中满是错误，根本无法稳定运行。重构还不如重新写一个来的简单。
在项目的最后期限，应该避免重构。 在此时机，从重构过程赢得的生产力只有在最后期限过后才能体现出来，而那个时候已经为时晚矣。如果最后没有足够时间重构，通常就表示你其实早就应该重构。
Ward Cunningham把未完成的重构工作形容为“债务”。很多公司都需要借债来使自己更有效的运转。你可以承受一定程度的利息，但如果利息太高你就只能被压垮。把债务管理好是很重要的，你应该随时通过重构来偿还一部分的债务。
五、代码的坏味道
重复代码(Duplicated Code)：首当其冲，如果你在一个以上的地点看到相同的程序结构，那么可以肯定：设法将它们合而为一，程序会变的更好。
过长函数(Long Method)：程序越长越难理解，应该积极的分解函数。每当我们想通过注释说明点什么的时候，我们就需要把说明的东西写进一个独立的函数。
过大的类(Large Class)：单个类做太多事情，内部往往出现太多实力变量，一旦如此，重复代码也就接踵而至了。
过长参数列(Long Parameter List)：太长的参数会造成前后不一致，不易使用，而且一旦需要更多数据，就不得不修改它。如果将对像传递给函数，大多数修改将没有必要。
发散式变化(Divergent Change)：一个类受多种变化的影响，我们应该找出某特定原因造成的所有变化，然后将他们提炼到另一个类中。
霰弹式修改(Shotgun Surgery)：如果遇到某种变化，都要在许多不同类中作出许多小修改。如果需要修改的代码散布四处，不但很难找到它们，也很容易忘记某个重要的修改。
依恋情结(Feature Envy)：函数对某个类的兴趣高过自己所处类的兴趣（某个函数为了计算某个值从另一个对象那儿调用几乎半打的取值函数）
数据泥团(Data Clumps)：相同的若干项数据出现在不同地方，这些总是绑在一起出现的数据应该有属于它们自己的对象
基本类型偏执(Private Obsession)：很多人不愿意在小任务上运用小对象（像是结合数值和币种的money类，由一个起始值和一个结束值组成的range类、电话号码或邮政编码等的特殊字符串）
switch惊悚现身(Switch Statements)：switch出现的地方考虑是否可以用子类取代类型码，用状态模式／策略模式取代类型码，用多态取代条件表达式
冗赘类(Lazy Class)：如果一个类不值得存在，那就让它消失（不论重构使它身型缩水；或是开发者过度设计来应对并没有发生的变化）
夸夸其谈的未来星(Speculative Generality)：预留的无用的抽象类，无用的抽象参数
令人迷惑的暂时字段(Temporary Field)：类中某个字段只为某些特殊情况而设置。（在变量未被使用的情况下猜测当初设置的目的，会让人疯掉的）
中间人(Middle Man)：无用的委托，过多的中间层
狎昵关系(Inappropriate Intimacy)：两个类过于亲密，一个类过于关注另一个类的成员（要么拆散，严守清规；要么把共同点提炼到一个新类中）
异曲同工的类(Alternative Classes with Different Interfaces)：不同名字的类或函数，做着相同的事
被拒绝的遗赠(Refused Bequest)：子类不想继承超类所有的函数和数据，只想挑几样来玩。复用了超类行为，却不愿意支持超类的接口，可以考虑使用委托代替继承
过多的注释(Comments)：并不是说不应该写注释，注释是好的习惯，但是不能当作除臭剂来使用。你看到一段代码有着长长的注释，然后发现这些注释之所以存在乃是因为代码太糟糕。当你感觉需要撰写注释时，请先尝试重构，试着让所有的注释都变得多余。
六、构筑测试体系
- 重构的首要前提是拥有一个可靠的测试环境。
- 只要写好一点功能，就立即添加测试，并确保所有测试都完全自动化，让它们检查自己的测试结果。一套测试就是一个强大的bug侦测器，能够大大缩减查找bug所需要的时间。
- 撰写测试代码的最有用时机是在开始编程之前。当你需要添加特性的时候，先写相应测试代码。编写测试代码其实就是在问自己：添加这个功能需要做些什么。编写测试代码还能使你把注意力集中于接口而非实现。预先写好的测试代码也为你的工作安上一个明确的结束标志：一旦测试代码正常运行，工作就可以结束了。
- 多运用单元测试。测试你最担心出错的地方，考虑可能出错的边界条件。不要因为测试无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug。“花合理时间抓出大多数bug”要好过“穷尽一生抓出所有bug”。
七、重新组织函数
提炼函数（Extract Method）。你有一段代码可以被组织在一起并独立出来。将这段代码放进一个独立函数中，并将函数名称解释该函数的用途。
内联函数（Inline Method）。一个函数的本体与名称同样清楚易懂。在函数调用点插入函数本体，然后移除该函数。
内联临时变量（Inline Temp）。你有一个临时变量，只被一个简单表达式赋值一次，而它妨碍了其他重构手法。将所有对该变量的引用动作，替换为对它赋值的那个表达式自身。
以查询取代临时变量（Replace Temp with Query）。你的程序以一个临时变量保存某一表达式的运算结果。将这个表达式提炼到一个独立函数中。将这个临时变量的所有引用点替换为对新函数的调用。此后，新函数就可被其他函数使用。
引入解释性变量（Introduce Explaining Variable）。你有一个复杂的表达式。将该复杂表达式（或其中一部分）的结果放进一个临时变量，以此变量名称来解释表达式用途。
分解临时变量（Split Temporary Variable）。你的程序有某个临时变量被赋值过一次，它既不是循环变量，也不被用于收集计算结果。针对每次赋值，创造一个独立、对应的临时变量。
移除对参数的赋值（Remove Assignments Parameters）。代码对一个参数进行赋值。以一个临时变量取代参数的位置。
以函数对象取代函数（Replace Method with Method Object）。你有一个大型函数，其中对局部变量的使用使你无法采用Extract Method。将这个函数放进一个单独对象中，如此一来局部变量就成了对象内的字段。然后你可以在同一个对象中将这个大型函数分解为多个小型函数。
替换算法（Substitute Algorithm）。你想要把某个算法替换为另一个更清晰的算法。将函数本体替换为另一个算法。
八、在对象之间搬移特性
搬移函数（Move Method）。你的程序中，有个函数与其所驻之外的另一个类进行更多交流：调用后者，或被后者调用。在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数，或是将旧函数完全移除。
搬移字段（Move Field）。你的程序中，某个字段被其所驻类之外的另一个类更多地用到。在目标类新建一个字段，修改源字段的所有用户，令它们改用新字段。
提炼类（Extract Class）。某个类做了应该有两个类做的事。建立一个新类，将相关的字段和函数从旧类搬移到新类。
将类内联化（Inline Class）。某个类没有做太多事情。将这个类的所有特性搬移到另一个类中，然后移除原类。
隐藏“委托关系”（Hide Delegate）。客户通过一个委托来调用另一个对象。在服务类上建立客户所需的所有函数，用以隐藏委托关系。
移除中间人（Remove Middle Man）。某个类做了过多的简单委托动作。让客户直接调用受托类。
引入外加函数（Introduce Foreign Method）。你需要为提供服务的类增加一个函数，但你无法修改这个类。在客户类中建立一个函数，并以第一参数形式传入一个服务类实例。
引入本地扩展（Introduce Local Extension）。你需要为服务类提供一些额外函数，但你无法修改这个类。建立一个新类，使它包含这些额外函数。让这个扩展品成为源类的子类或包装类。
九、重新组织数据
自封装字段（Self Encapsulate Field）。你直接访问一个字段，但与字段之间的耦合关系逐渐变得笨拙。为这个字段建立取值/设值函数，并且只以这些函数来访问字段。
以对象取代数据值（Replace Data Value with Object）。你有一个数据项，需要与其他数据和行为一起使用才有意义。将数据项变成对象。
将值对象改为引用对象（Change Value to Reference）。你从一个类衍生出许多彼此相等的实例，希望将它们替换为同一个对象。将这个值对象变成引用对象。
将引用对象改为值对象（Change Reference to Value）。你有一个引用对象，很小且不可变，而且不易管理。将它变成一个值对象。
以对象取代数据（Replace Array with Object）。你有一个数组，其中的元素各自代表不同的东西。以对象替换数组，对于数组中的每个元素，以一个字段来表示。
**复制“被监视数据”（**Duplicate Observed Data）。你有一些领域数据置身GUI控件中，而领域函数需要访问这些数据。将该数据复制到一个领域对象中。建立一个Observe模式，用以同步领域对象和GUI对象内的重复数据。
将单向关联改为双向关联（Change Unidirectional Association to Bidirectional）。两个类都需要使用对方特性，但其间只有一条单向链接。添加一个反向指针，并使修改函数能够同时更新两条链接。
将双向关联改为单向关联（Change Bidirectional Association to Unidirectional）。两个类之间有双向关联，但其中一个类如今不再需要另一个类的特性。去除不必要的关联。
以字面常量取代魔法数（Replace Magic Number with Symbolic Constant）。你有一个字面数值，带有特别含义。创造一个常量，根据其意义为它命名，并将上述的字面数值替换为这个常量。
封装字段（Encapsulate Field）。你的类中存在一个public字段。将它声明为private，并提供相应的访问函数。
封装集合（Encapsulate Collection）。有个函数返回一个集合。让这个函数返回该集合的一个只读副本，并在这个类中提供添加/移除集合元素的函数。
以数据类取代记录（Replace Record with Data Class）。你需要面对传统编程环境中的记录结构。为该记录创建一个“哑”数据对象。
以类取代类型码（Replace Type Code with Class）。类之中有一个数值类行码，但它并不影响类的行为。以一个新的类替换该数值类型码。
以子类取代类型码（Replace Type Code with Subclass）。你又一个不可变的类型码，它会影响类的行为。以子类取代这个类型码。
以State/Strategy取代类型码（Replace Type Code with State/Strategy）。你有一个类型码，它会影响类的行为，但你无法通过继承手法消除它。以状态对象取代类型码。
以字段取代子类（Replace Subclass with Fields）。你的各个子类的唯一差别只在“返回常量数据”的函数身上。修改这些函数，使他么返回超类中的某个（新增）字段，然后销毁子类。
十、简化条件表达式
分解条件表达式（Decompose Conditional）。你有一个复杂的条件（if-then-else）语句。从if、then、else三分段落中分别提炼出独立函数。
合并条件表达式（Consolidate Conditional Expression）。你有一系列条件测试，都得到相同结果。将这些测试合并为一个条件表达式，并将这个条件表达式提炼成为一个独立函数。
合并重复的条件片段（Consolidate Duplicate Conditional Fragments）。在条件表达式的每个分支上有着相同的一段代码。将这段重复的代码搬移到条件表达式之外。
移除控制标记（Remove Control Flag）。在一系列布尔表达式中，某个变量带有“控制标记”的作用。以break语句或return语句取代控制标记。
以卫语句取代嵌套条件表达式（Replace nested Conditional with Guard Clauses）。函数中的条件逻辑使人难以看清正常的执行路径。使用卫语句表现所有的特殊情况。
以多态取代条件表达式（Replace Conditional with Polymorphism）。你手上有个条件表达式，它根据对象类型的不同选择不同的行为。将这个条件表达式的每个分支放进一个子类内的覆写函数中，然后将原始函数声明为抽象函数。
引入Null对象（Introduce Null Object）。你需要再三检查某对象是否为null。将null值替换为null对象。
引入断言（Introduce Assertion）。某一段代码需要对程序状态做出某种假设。以断言明确表现这种假设。
十一、简化函数调用
函数改名（Rename Method）。函数的名称未能揭示函数的用途。修改函数的名称。
添加参数（Add Parameter）。某个函数需要从调用端得到更多信息。为此函数添加一个对象参数，让该对象带进函数所需信息。
移除参数（Remove Parameter）。函数本体不再需要某个参数。将该参数去除。
将查询函数和修改函数分离（Separate Query from Modifier）。某个函数既返回对象状态值，又修改对象状态。建立两个不同的函数，其中一个负责查询，另一个负责修改。
令函数携带参数（Parameterize Method）。若干函数做了类似的工作，但在函数本体中却包含了不同的值。建立单一函数，以参数表达那些不同的值。
以明确函数取代参数（Replace Parameter with Explicit Methods）。你有一个函数，其中完全取决于参数值而采取不同行为。针对该参数的每一个可能值，建立一个独立函数。
保持对象完整（Preserve Whole Object）。你从某个对象中取出若干值，将它们作为某一次函数调用时的参数。改为传递整个对象。
以函数取代参数（Replace Parameter with Methods）。对象调用某个函数，并将所得结果作为参数，传递给另一个函数。而接受该参数的函数本身也能够调用前一个函数。让参数接受者去除该项参数，并直接调用前一个函数。
引入参数对象（Introduce Parameter Object）。某些参数总是很自然地同时出现。以一个对象取代这些参数。
移除设值函数（Remove Setting Method）。类中的某个字段应该在对象创建时被设值，然后就不再改变。去掉该字段的所有设值函数。
隐藏函数（Hide Method）。有一个函数，从来没有被其他任何类用到。将这个函数修改为private。
以工厂函数取代构造函数（Replace Constructor with Factory Method）。你希望在创建对象时不仅仅是做简单的构建动作。将构建函数替换为工厂函数。
封装向下转型（Encapsulate Downcast）。某个函数返回的对象，需要由函数调用者执行向下转型。将向下转型动作移到函数中。
以异常取代错误码（Replace Error Code with Exception）。某个函数返回一个特定的代码，用以表示某种错误情况。改用异常。
以测试取代异常（Replace Exception with Test）。面对一个调用者可以预先检查的条件，你抛出了一个异常。修改调用者，使它在调用函数之前先做检查。
十二、处理概括关系
字段上移（Pull Up Field）。两个子类拥有相同的字段。将该字段移至超类。
函数上移（Pull Up Method）。有些函数，在各个子类中产生完全相同的结果。将该函数移至超类。
构造函数本体上移（Pull Up Constructor Body）。你在各个子类中拥有一些构造函数，他们的本体几乎完全一致。在超类中新建一个构造函数，并在子类构造函数中调用它。
函数下移（Push Down Method）。超类中的某个函数只与部分（而非全部）子类有关。将这个函数移到相关的那些子类去。
字段下移（Push Down Field）。超类中的某个字段只被部分（而非全部）子类用到。将这个字段移到需要它的那些子类去。
提炼子类（Extract Subclass）。类中的某些特性只被某些（而非全部）实例用到。新建一个子类，将上面所说的那一部分特性移到子类中。
提炼超类（Extract Superclass）。两个类有相似特性。为这两个类建立一个超类，将相同特性移至超类。
提炼接口（Extract Interface）。若干客户使用类接口中的同一子集，或者两个类的接口有部分相同。将相同的子集提炼到一个独立接口中。
折叠继承体系（Collapse Hierarchy）。超类和子类之间无太大差别。将它们合为一体。
塑造模板函数（Form TemPlate Method）。你有一些子类，其中相应的某些函数以相同顺序执行类似的操作，但各个操作的细节上所有不同。将这些操作分别放进独立函数中，并保持它们都有相同的签名，于是原函数也就变得相同了。然后将原函数上移至超类。
以委托取代继承（Replace Inheritance with Delegation）。某个子类只使用超类接口中的一部分，或是根本不需要继承而来的数据。在子类中新建一个字段用以保存超类；调整子类函数令它改而委托超类；然后去掉两者之间的继承关系。
以继承取代委托（Replace Delegation with Inheritance）。你在两个类之间使用委托关系，并经常为整个接口编写许多极简单的委托函数。让委托类来继承受托类。
十三、大型重构
梳理并分解继承体系（Tease Apart Inheritance）。某个继承体系同时承担两项责任。建立两个继承体系，并通过委托关系让其中一个可以调用另一个。
将过程化设计转化为对象设计（Convert Procedural Design to Objects）。你手上有一些传统过程化风格的代码。将数据记录变成对象，将大块的行为分成小块，并将行为移入相关对象之中。
将领域和表述/显示分离（Separate Domain from Presentation）。某些GUI类之中包含了领域逻辑。将领域逻辑分离出来，为它们建立独立的领域类。
提炼继承体系（Extract Hierarchy）。你有某各类做了太多工作，其中一部分工作是以大量条件表达式完成的。建立继承体系，以一个子类表示一种特殊情况。