2019-03-08重构：改善既有代码设计阅读笔记(一)

一、

1.重构的必要性：改善软件设计、利用重构来协助理解不熟悉的代码、帮助找到bug、重构提高编程速度。

2、重构的时机“：三次法则，添加功能时重构、修补错误时重构、复审代码时重构。重构的原动力，代码的设计无法帮助轻松添加需要的特性。计算机科学本质：相信所有问题都可以通过增加一个中间层来解决。

3、间接层的价值：允许逻辑共享、分开解释意图和实现、隔离变化、封装条件逻辑。

4、重构的困难：数据库模型与代码耦合（在对象模型和数据库模型之间加入中间层）、接口发布后接口的修改（尽量不要更改已经发布的接口，可以用新接口调用旧的接口）。如果代码不能正常稳定运行，不应该进行重构，应该进行重写。

5 预先设计和重构的关系：预先设计不用太严密，只要有一个足够合理的解决方案就可以了，不必找出一定正确的解决方案。

6.重构与性能：应该对程序进行分析，找到性能瓶颈点，然后对性能热点代码进行重构，因为一个系统中90%的代码都很少被执行。

二、

1.重复代码（Duplicated Code）:同一个类的两个函数含有相同的表达式、两个互为兄弟的子类含有相同的表达式、两个毫不相关的类出现了重复代码。此时应该进行方法的抽取。

2.过长函数（Long Method）:1、间接层所能带来的全部利益————解释能力、共享能力、选择能力————都是由小型函数支持的。2、程序越长越难理解。3、现在oo语言完全免除了进程内的函数调用开销，可尽情使用小函数。3、小函数真正需要的是一个好名字。4、每当感觉需要以注释说明点什么的时候，就需要把说明的东西写进一个独立函数中，并以其用途命名（而非实现手法）。5、函数内有大量的参数和临时变量，会对函数提炼形成障碍，将临时变量和参入传递给提炼出来的新函数，可读性不会有明显的提升。

3.过大的类（Large Class）:1、单个类做太多事情，内部往往会出现很多实例变量，会导致重复代码。类中有大量代码，也跟代码重复、混乱的效果差不多。

4.过长参数列（Long Parameter List）:1、使用对象技术，不必把函数所需要的所有东西都以参数传递给它了。2、若不希望“被调用对象“和“较大对象”间的某种依赖关系。可以将数据从对象中拆解出来单独作为参数，也是合理措施。

5.发散式变化（Divergent Change）:1、针对某一外界变化的所有相应的修改，都应该发生在单一类中。2、若新加入一个功能，必须修改多个函数，那么类就应该分成更小的。3、应该找到多个函数同时变化的原因，抽取一个新的类来反映这种变化。

6.霰弹式修改（Shotgun Surgery）:1、遇到某种变化，都必须在许多不同的类内做出小修改，需要修改的代码散步四处，不但很难找到他们，也可能很容易忘记某个重要的修改。2、应该使用移动方法和移动字段将所有需要修改的代码放进同一个类。跟上面的这个有些类似。

7.依恋情结（Feature Envy）:1、函数对某个类的兴趣搞过对自己所处类的兴趣是一种坏味道。     2、判断哪个类拥有最多被此函数使用的数据，然后就把这个函数和那些数据摆在一起。3、根本原则：将总是一起变化的东西放在一块。

8.数据泥团（Data Clumps）:1、总是绑在一起出现的数据应该拥有属于他们自己的对象。首先应该找出数据以字段形式出现的地方，将它们抽取为一个独立的类。

9.基本类型偏执（Primitive Obsession）:1、对象的极大价值：模糊（打破）了于横亘于基本数据和体积较大的类之间的界限。2、要愿意在小任务上使用小对象————像是结合数值和币种的money类。

10.switch惊悚现身（Switch Statements）:1、面向对象程序的一个最明显的特征就是：少用switch(或case)语句。从本质上来说，switch语句的问题在于重复。2.同样的switch语句经常会散布与不同地点。如果要为它添加一个新的case字句，就必须找到所有的switch语句并修改他们，可以使用多态来优雅的解决这个问题。3.switch语句常常根据类型码来选择，你要的是“与该类型码相关的函数或类”，所以应该使用抽取Extract Method 将switch语句提炼到一个独立函数中，再移动方法将它搬移到需要多态性的那个类里面。