《重构--改善既有代码的设计》读书笔记
1为什么重构有用
所有有意义的事情总结下来，都是完成了一个有用的功能，或者解决一个问题。
作者总结了4个程序的问题：
1. 难以阅读的程序，难以修改
我的理解：1 本身业务逻辑就很复杂，且程序员对其理解很表面，不能把复杂的业务逻辑抽象为简单逻辑的组合。
2 个别程序员的思维逻辑和大众不太一样，也没有学习设计模式，使用自己的思维逻辑去编写代码，并且不遵循编码规范，导致维护人员很难理解其代码。
2.逻辑重复的程序，难以修改
我的理解：这类问题较容易发现，对于某些新项目，程序员再没有全面了解的情况下，会写重复代码，所以接手新项目前，需要大致的了解代码结构，模块的划分，每个模块的大概内容。
另外就是程序员开发过程中会因为工期问题，直接copy其它模块的代码，而不想如何重构代码，让这块代码由私有变为公有。这里就是技术负责人可以改进的地方了，例如和产品经理协商工期，代码reivew发现问题，向组内成员鼓励重构。
3.添加新行为时需要修改已有代码的程序，难以修改
我的理解：优秀的，有经验的开发人员会在第一版设计的时候预计到一些有可能的变更，会用面向对象的思维和设计模式写出 代码逻辑和业务逻辑一致，易阅读，易扩充的代码，但是个人认为这个不是最重要的，第一版的时候 也许业务逻辑很简单，并不需要设计很多的类和模块，但是当迭代开发到某一版时，业务逻辑开始变得复杂，那么模块和类的设计应该是这一版开发人员的责任，而不能说之前是这么写的，我也不需要改进。
4.带复杂条件逻辑的程序，难以修改
同1的第一种原因，需要开发人员高度的抽象，分解能力。
以下为我的补充
5. 大的开发项目 ，模块划分不明确，耦合严重，开发人员开发不同功能，代码缺经常冲突。
所以作者认为 好的程序应该是：（1）容易阅读；（2）所有逻辑都只在唯一地点指定；（3）新的改动不会危及吸纳有行为；（4）尽可能简单表达条件逻辑。
重构就是这样一个过程，再不改变程序逻辑行为的前提下，解决提到的4个问题，使其满足好程序的4个标准。
作者也举了自己的一个例子，作为一个顾问，调研客户的一个项目，在项目中期，作者建议花2周时间做一次重构，但是项目经理因为工期问题拒绝，6个月后，该项目因为代码太复杂，无法维护修改，性能不达标，被推倒重新开发。
那些代码需要重构
1. 重复代码
2. 过长函数
3.过大的类
4.过长的参数列：改为用对象传值
5.发散式变化：如果要更改对象的一项功能，需要修改某几个功能，那么这几个功能应该在一个类中，另一项功能的几个相关函数应该在另一个类中。
6.散弹式修改：如果你修改一个功能时，需要更改很多个类，那么需要考虑这些函数是否应该放在同一个类中。
7 依恋特性：如果一个函数对某个类的使用（依恋）大于自己所处的类，那么就应该把这个函数移到最依恋的类中去。
8 数据块，如果几项数据总是同时出现，同时被使用，那么可能需要把这几项数据合并到一个新类中去。
9基本类型偏执：TODO
10 switch语句：尽可能少用switch 而是用多态来代替它。
