一. 这本书在谈什么？
《重构》是程序员里面很经典的一本书，有人曾说，做面向对象开发，就是左手设计模式，右手重构，说的很在理。其实重构的方法和逻辑也都是基于设计原则的，比如单一职责原则，最少知识原则。当然，重构的前提是在不改变对原有系统的功能的基础之上做的设计优化，可以提高其可理解性，降低其修改成本。
二. 这本书细节部分都讲了什么？
1.重构的方法论
- 重构也是避免你的代码越来越复杂和难以维护的重要手段，当你发现你的代码已经很难添加新的功能时，就要考虑是否重构了。
- 作者提到一个重构的关键做法，就是测试，引入测试，是确保你的重构能够正常和确保原有系统功能的重要保证。而且提倡你小步快跑，而不是每次重构都变得难以恢复，应该是改一点，测一点，直到全部重构完成。另外，测试不需要测试所有的功能，而应该放在你觉得容易出错的地方即可。
- 改进设计的一个重要方向就是消除重复代码。
- 良好的设计是快速开发的根本
- 重构往往是把大型对象拆成多个小型对象，把大型函数拆成多个小型函数，这个和架构设计里面常说的“分而治之”有异曲同工之妙。
2. 几个关键的认知
- 让代码自解释，好的代码应该是不需要注释就能让别人能够看懂，明白你的代码逻辑的，因此，包括变量名、方法名等都应该做好清楚，明白。
- 函数和它说使用的数据应该放在一起，如果出现函数和数据分离的情况，就要考虑重构了。
- 如果if/else，switch出现的很多，也要考虑重构，重构的技巧是使用多态。
3. 怎么判断代码是否要重构
- 重复代码
- 如同一类中的两个函数有相同的表达式：抽取出来做独立函数；
- 两个互为兄弟的子类内含相同的表达式： 推入超类；
- 两个不相关的类出现重复代码：提炼到一个独立类中。
- 过长代码
- 拆分然后让小函数有容易理解的名字；
- 有过多注释时：拆分为独立函数；
- 条件和循环：提炼到独立函数。
- 过大的类
- 抽取和拆分类，将数据和行为移到一个独立的领域对象中。
- 过长的参数列
- 太长的参数列难以理解，太多参数容易造成前后不一致、不易使用，而且一旦你需要更多数据，就不得不修改它。
- 发散式变化
- 如果一个类经常因为不同的原因在不同的方向上变化，那就需要将变化的部分迁移到一个新类中。
6.霰弹式修改
- 如果遇到变化，需要在许多不同的小类中作出很多小修改，那就需要把一系列相关行为放到一个类中。
- 依恋情节
- 将数据和对数据的操作行为包装在一起。这也是封装的终极追求。
- 数据泥团
- 总是绑在一起的数据应该拥有他们自己的对象
- switch
- 面向对象的一个明显特征是：少用switch，应该用多态来替换它。当然，如果只是在一个单一函数中有些选择事例，且不会变化，那就不需要用多态。
10.其他一些情况
- 过度使用委托，如中间委托类承担了原来类中大半的函数了，那就应该取消中间类，直接让两个对象发生关系
- 过度使用继承，会造成耦合严重，这时候应该考虑去掉继承关系
4. 重构的一些小技巧
- 对于临时变量，如果他们被赋值超过一次，那就意味着他们在函数中承担了一个以上的责任。应该替换成多个临时变量。
- 避免对参数进行赋值。（跟使用被传入对象的操作不同）
- 数据隐藏，不要使用public来修饰数据。
- 将查询函数和修改函数分离
三. 总结
其实重构没有想象中那么复杂，遵循的原则也无非的单一职责、最少知识原则、封装等基础的面向对象的概念，重构不过是按照这些原则来开展代码优化的具体实践，最重要的还是要在工作中结合使用，将这些知识变成自己的技能和习惯，写出好的代码，才能在以后运维中少吃点亏。
