读 《重构-改善既有代码的设计》 要点记录 [TOC] 书本的年代：作者在写此书时还在流行使用java1.1, 我在读这本书时流行java7和8.

重构的定义：

1. 对软件内部 结构 的一种调整，目的是在不改变【软件之可察行为】前提下，提高其可读性， 降低修改成本。

2. 使用一系列重构准则，在不改变【软件之可察行为】前提下，调整其结构

为何重构？

　如果没有重构，程序 的设计 会逐渐腐败变质 。 　重构 使软件更易被理解。 　重构的确能够提高生产力 　如果没有重构就必须保证【预先设计】正确无误，毫无差池。

:-:asdf:-:

重构方法

1.过长的方法

拆分成若干 表达明确小方法

2.过长的类

拆分

3.重复的代码

方法提取，重用

4.使用了太多的间接层

确认其不具多态性，删了这些不必要的委托

5.以查询取代临时变量(局部变量)

临时变量会驱使你天之写出更长的函数，减少他们。

6.循环变量 集用临时变量

临时变量应该只被赋值一次，只承担一个责任。 
如果同一个临时变量承担两件不同的事情， 会令代码难以阅读。

7.移除对参数的赋值动作

注：由于作者还停留在java只能按值传递的java1.1年代， 所以和现在有所区别

8.替换新的算法

如果有更简单、优秀的算法出现时

9.搬移函数

何时不该重构？

1. 重构不如重写来得简单的时候。
2. 项目接近最后期限

重构目标：

代码复用，去除重复代码。

Tip: 如果你发现自己需要为程序 添加一个特性， 而代码 结构 使你无法很方便 地那么做， 那就先重构那个程序 ， 使特性的添加比较容易 进行， 然后再添加特性。

重构的关键： 可靠的测试(单元测试的重要地位)

重构时最好小步前进，编译并测试（文中指测试脚本），确保没有破坏任何东西，使犯错的几率降到最小 重构和优化，分为两个不同目标下所产生的行为，区别对待、不混淆。

书中有大量篇幅用来介绍 JUnit 单元测试法、用法。 不断丰富单元测试代码使它能在重构过程中及时的发现bug。

当测试数量达到一定程度之后，测试效益会呈现递减态势，而非持续递增，应该把测试集中在可能出错的地方。

两顶帽子

添加新功能

添加新功能 时，你不应该修改既有代码 ，只管添加新功能 。

重构

重构时你就不能再添加功能 ，只管改进程序结构。

重构ＶＳ设计　

　　虽然这是不最有效的途径，但是将重构作为‘预先设计’的替代品，　不必做任何设计， 只管按照最初想法开始编码，让代码有效运作，然后再将它重构成型这种方式是可行的。 　　如果没有重构就必须保证【预先设计】正确无误，毫无差池。

灵活ＶＳ简单

灵活的解决方案总是比简单的解决方案复杂许多，　最终得到的软件通常复杂度更高\更难维护。 其中肯定有些灵活性的确派不上用声，但你无法预测到底是哪些派不上用场　，为了获得想要的灵活性，　 你不得不加入比实际需要更多的灵活性。 追求灵活容易劳而无获。 而重构可以带来简单的设计　，同时又不损失灵活性。

代码性能优化

如果一视同仁的优化所有代码，９０％的工作都是白费劲。 重构的确会使软件变慢，但它使优化阶段中的软件性能调整更容易 避免猜测性能问题所在，而是要实际量度系统