《重构 改善既有代码的设计 1》重构原则

前言

重构 既有代码的设计，一本经典神书，两年前入手，一年前看了一半，感觉一般般，今天起，再次拜读，希望会有不一样的收获！

/**
* @startTime 2020-12-16 23:22
* @endTime 2020-12-16 23:59
* @startPage 1 
* @endPage 55
* @efficiency 56/1 = 56页/天
* @needDays 412/56 = 7天
* @overDay 2020-12-16 + 7天 = 2020-12-22 
*/

第1章 重构，第一个案例

所谓重构，是在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构是一种千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减少整理过程中引入错误的几率。本质上说，重构就是在代码写好之后改进它的设计。

任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员。

第2章 重构原则

1、何谓重构

对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。

重构的目的是使软件更容易被理解和修改。

越难看出代码所代表的设计意图，就越难保护其中的设计，经常性的重构可以帮助代码保持自己该有的形态。完成同一件事，设计不良的程序往往需要更多的代码，这常常是因为代码在不同的地方使用完全相同的语句做同样的事情。因此改进设计的一个重要方向就是消除重复代码，这个动作的重要性在于方便未来的修改。代码量减少并不会使系统运行更快，因为这对程序运行轨迹几乎没有任何明显影响。然而代码量减少将使未来可能的程序修改动作容易得多。

/**
* @startTime 2020-12-17 22:00
* @endTime 2020-12-17 22:50
* @startPage 56 
* @endPage 64
* @efficiency 64/2 = 32页/天
* @needDays 412/32 = 13天
* @overDay 2020-12-16 + 13天 = 2020-12-29 
*/

2、重构使软件更容易理解

让review的人更容易理解，让下一个接手你代码的人，更容易理解。也许下一个接手你代码的人就是你自己。有的时候，一段代码拿过来，是不是你自己写的，你都确定不了，对吧？

• 重构的好处
• 重构帮助找到bug
• 重构提高编程速度

3、重构的时机

• 事不过三，三则重构
• 添加功能时重构
• 修改错误时重构
• 复审代码时重构

4、为什么重构有用

1. 难以阅读的程序，难以修改；
2. 逻辑重复的程序，难以修改；
3. 添加新行为时需要修改已有代码的程序，难以修改；
4. 带复杂条件逻辑的程序，难以修改；

因此，我们希望程序：

1. 容易阅读；
2. 所有逻辑都只在唯一地点指定；
3. 新的改动不会危及现有行为；
4. 尽可能简单表达条件逻辑；

间接层和重构

间接层的价值：

1. 允许逻辑共享；
2. 分开解释意图和实现；
3. 隔离变化；
4. 封装条件逻辑；

5、重构的难题

（1）数据库

数据迁移

（2）修改接口

不要过早发布接口，请修改你的代码所有权政策，使重构更顺畅。

（3）难以通过重构手法完成的设计改动

（4）何时不该重构 

/**
* @startTime 2020-12-20 11:50
* @endTime 2020-12-20 15:30
* @startPage 65 
* @endPage 102
* @efficiency 102/5 = 20.4页/天
* @needDays 412/20.4 = 20天
* @overDay 2020-12-16 + 20天 =  2020-01-04
*/

6、重构和设计

很多人都把设计看做软件开发的关键环节，而把编程看做只是机械式的低级劳动。他们认为设计就像画工程图而编码就像施工。

哪怕你完全了解系统，也请实际度量它的性能，不要臆测。臆测会让你学到一些东西，但十有八九你是错的。

7、重构和性能

首先写出可调的软件，然后调整它以获得足够的速度。

三种编写快速软件的方法：

（1）时间预算法

通常用于性能要求极高的实时系统。

分解设计时要做好预算，给每个组件预先分配一定的资源，包括时间和执行轨迹。每个组件决不能超出自己的预算，就算拥有组件之间的调度预配时间的机制也不行。

这种方法高度重视性能，对于心率调节器一类的系统是必须的，因为这样的系统中迟来数据就是错误的。但对一些管理系统来说，如此追求性能就有点过分了。

（2）持续关注法

这种方法要求任何程序员在任何时间做任何事情时，都要设法保证系统的高性能。

这种方法看起来很常见，感觉上很有吸引力，但通常不会起太大作用。

（3）性能优化阶段

编写程序时，不用将过多的精力关注在性能上，在代码开发完毕之后，会有一个性能优化阶段，一旦进入该阶段，就按照某个特定程序来调整程序性能。

在性能优化阶段，首先应该用一个度量工具来监控程序的运行，让它告诉你程序中哪些地方大量消耗时间和空间。这样就可以找出性能热点所在的一小段代码。然后应该集中关注这些热点代码，并使用持续关注法中的优化手段来优化它们。每走一步都需要编译、测试、再次度量。

8、重构起源何处

第三章 代码的坏味道

1、重复代码

同一个类中两个函数含有相同的表达式时，就要提炼出重复的代码，然后让这两个地点都调用被提炼出来的那一段代码。

2、过长函数

间接层所带来的全部利益，解释能力、共享能力、选择能力。

应该更积极的分解函数，每当感觉需要注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名，我们甚至可以对一组甚至一行代码做这件事。哪怕替换后的函数调用动作比函数自身还长，只要函数名称能够解释其用途，我们也该毫不犹豫的这么做。关键不在于函数的长度，而在于函数“做什么”和“如何做”之间的语义距离。

（1）提炼函数

（2）以查询取代临时变量

（3）引入参数对象或保持对象完整

（4）以函数对象取代函数

将这个特函数放进一个单独对象中，如此一来局部变量就变成了了对象内的字段，然后你可以在同一个对象中将这个大型函数分解成多个小型函数。

本书在不断强调小型函数的优美动人。

（5）条件表达式和循环常常也是提炼的信号。

分解条件表达式；

将循环和其内的代码提炼到一根独立函数中。

3、过大的类

如果想利用单个类做太多事情，其内就会出现太多实例变量。一旦如此，重复代码也就接踵而至了。

可以利用提炼类将几个变量一起提炼至新类中。

4、过长参数列

5、发散式变化

6、散弹式修改

如果遇到某种变化，都必须在很多不同的类中做一些小修改的时候，你就可以将这些一起变化的代码提炼到一个新的类中。

7、依恋情节

函数对某个类的兴趣高多对自己所处类的兴趣，这时就需要转移函数的位置了。

8、数据泥团

一个好的评判方法是：删除众多数据中的一项时，其它数据有没有因而失去意义？如果它们不再有意义，这就是一个明确的信号，你就应该产生一个新对象。

减少字段和参数的个数，当然可以去除一些坏味道，但更重要的是：一旦拥有新对象，就有机会让程序散发出一种芳香。得到新对象后，你就可以着手寻找依恋情节，这可以帮你指出能够移至新类中的种种程序行为。不必太久，所有的类都将在它们小小社会中充分发挥价值。

9、基本类型偏执

对象技术的新手通常不愿意在小任务上运用小对象，像结合数值和币种的money类、电话号码、邮政编码等的特殊字符串，看似简单，此时可以运用以对象取代数据值，将原本单独存在的数据值替换为对象，从而走出传统的洞窟，进入炙手可热的对象世界。

10、switch惊悚现身

面向对象程序的一个最明显特征就是：少用switch语句。

从本质上说，switch语句的问题在于重复。你常会发现同样的switch语句散布于不同地点。如果要为它添加一个新的case子句，就必须找到所有switch语句并修改它们。 面向对象中的多态就可以带来优雅的解决方法。

11、平行继承体系

如果你发现一个类增加一个子类，必须也为另一个类相应的增加一个子类。如果你发现某个继承体系的类名称前缀和另一个继承体系名称前缀完全相同，便是闻到了这种坏味道。

消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。如果再接再厉运用转移方法和转移字段，就可以将引用端的继承体系消匿于无形。

12、冗余类

折叠继承体系；

将类内联化；

13、夸夸其谈未来性

14、令人迷惑的暂时字段

15、多度耦合的消息链

16、中间人

17、暧昧关系

18、异曲同工的类

19、不完美的类库

引入外加函数，即对复杂参数的封装；

引入本地扩展，即继承类库并添加你需要的方法；

20、纯稚的数据类

21、被拒绝的馈赠

以委托替代继承。

22、过多的注释

当你看到一堆注释的时候，往往是因为你的代码很糟糕，需要用注释去解释它。所以过多的注释就预示着你该对代码进行重构了。

当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余。

第四章 构筑测试体系

1、自测试代码的价值

实际上编写测试代码的最有用时机是在开始编程之前。当你需要添加特性的时候，先写相应测试代码。

编写测试代码其实就是在问自己，添加这个功能需要做些什么。编写测试代码还能使你把注意力集中于接口而非实现。

2、JUnit测试框架

3、添加更多测试

• 编写未臻完善的测试并实际运行，好过对完美测试的无尽等待；
• 考虑可能出错的边界条件，把测试火力集中在那儿；
• 当事情被认为应该会出错时，别忘了检查是否抛出了预期的异常；
• 不要因为测试无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug；

上一篇：【编写高质量代码：改善Java程序的151个建议】

下一篇：《重构 改善既有代码的设计 2》重新组织函数、数据