《重构--改善既有代码的设计》读书笔记

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 而是用多态来代替它。