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

（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测试框架