读书：《改进既有代码的设计》之一（最好配合设计模式阅读，能相互印证）
原因：之前修改代码看心情和工作量。后来接触了一个小项目的重构工作，发现自己并没有系统的重构逻辑。所以觉得有必要
去学习一下。所以选择了上面说的两本书。以下作为自己看书的领悟和记录。
首先：为什么重构？
首先改善代码易读性，包括机器和人。
机器易读性：提高性能，减少冗余，分类清楚，保持健壮性的前提下尽量坚持单一职责原则。善用继承多态，提高代码利用率。
人的易读性：层次分明，规则明确，命名规范，尽量使方法短小易读，善用封装，减少方法复杂性，以及代码复用性。
第一章：
阅读第一个案例后总结：
- 分解重组。
把集成多个功能的方法分解，重组成多个方法。简化方法，提高易读性。
然后对应的方法，放到该放的位置，这点需要自己去判断。
作者观点：1.绝大多数情况下，函数应该放在它所使用的数据对象内部。2.重构最好小步前进，一步一步重构。避免犯错。
关键字：Replace Temp with Query,From Template Method
2. 多态的使用。
注意switch。提取公共接口。这里涉及到设计模式。当你使用switch的时候要注意了，可能这个点可能有重构使用多态的可能。
通过父类抽象一个方法，子类继承父类返回不同的code实现switch case。方法放对位置是关键。
3.重构方式。
从小的地方开始，如一个方法，或者几个属性，慢慢延伸到整个类，整个功能以致整个项目。关键一点是，每一个小的改
动都需要我们写对应的单元测试配合，保证代码不会有很大的失误。这样才能保证整个项目重构完成后更稳定和健壮。
所以重构的过程就是：小修改->测试->小修改->测试....直到完成。
第二，三章 ：
重构原则和代码的坏味道：
二：
1.何时重构，三次法则。一个东西反复修改或者有问题三次，你就需要重构。加功能重构，修补bug时重构。复审代码时重构。
2.重构涉及到数据库结构的时候比较麻烦。所以我们首先设计数据库的时候需要认真谨慎。然后降低数据实体跟对象之间的耦
合性。一般方法中间增加一个分割层。降低修改成本。
3.修改接口时要特别小心。牵一发动全身，了解业务，完全掌握接口的调用者，可以修改。
4.实在代码混乱不堪，花费时间比重写还多，建议重写。
三，代码坏味道：
1Duplicated Code.重复代码。记得以前学习时候老师的一句话“Don't repeat yourself”。当你发现你在重复你自己的时候，
说明代码有点坏味道了。想办法重新设计一下吧。
2.Long Method，过长函数。以前一个领导告诉我，一个方法不要超过多少多少行代码。当时我不理解。后来我发现，
往往我们比较长的方法内部其实实现了好几个功能。我为什么不分开这些功能呢？分开后还可以更加方便代码的重复利用。
这是想起了大学老师讲的单一职责了。
3.Large Class，太大的类。提炼新的类，细分不同的职责，这样之后你会突然发现你的文件也许放的位置是正确的了。
然后你的项目也许就有了一些约定。
4.Long Parameter List,过长的参数列。方法代替参数去重构。得到想要的。如果没法代替，想想依赖关系。
5.Divergent Change,发散式变化。说白了，就是多想想以后会有什么功能过来，来的时候你需要做的多不多？或者
有矛盾。在这时候你需要考虑清楚。也许你觉得你后边都考虑到了。那么请抬高你的业务视野，放眼整个项目，或者放眼相
关项目。站的够高业务越熟悉。这些才能想的越完善。用好Extract Class.
读到这里我发现第三章这些跟后边的章节依赖性很强。有点长，所以下一篇接着写吧。我先去理解去一下。
另：看书建议，最好配合设计模式去看。