当出现以下问题的时候，就要开始重构代码。
1）重复代码
重复代码在业务逻辑相同的地方，抽成方法。重复代码在业务逻辑不同的地方。抽成类。
2）long method
其实这个问题很多时候都碰到。我觉得原因主要还是两个。一个是修bug的时候，不敢改。因为这玩意，要改的话，压力还是很大的。还有一个写好之后，懒的改。这一种，特别实在这一次看书的过程中，觉得重构完全可以发生在刚写好代码的时候。因为我们写代码的时候，本能就是先实现功能。然后再考虑代码改如何组织。
3）large class
同上。
4）long parameter list
我现在遇到这种情况，比较喜欢把paramter抽象成一个类。
5）Divergent change（发散式变化）
某个class经常因为不同的原因在不同的方向上变化。
出现这个问题，觉得还是要从设计上考虑。不要操之过急。
6）shotgun Surgery（散弹式修改）
一个改变，多出修改。
根据经验，这种问题，第一个是懒，懒的抽到一个地方，然后一个一个地方改。第二个原因吗，是一些硬件或者知识储备不行。举个列子来说，给一个entry加一个新的属性。往往是从DAO层，要修改到UI层。这个有时候很难做到。
7）Feature Envy（依赖情节）
这里我觉得不绝对。比方说一些类，方法，起主要责任就是调度。这样势必会有很多依赖。
或者从另一个角度来说，如果一个类，或者方法，主要作用还是实现一个功能，那么一定要遵守这个规则。否者，还是看具体情况。
8）Data clumps（数据泥团）
我觉得这个还是看吧。还真不好说。
9）Primitive Obsession（基本类型偏执）
很有道理，但是会造成类的膨胀。不过这个还是主要依赖于设计。
10）switch statement
11）Parallel Inheritance Hierarchies(平行继承体系)
这个觉得不是很绝对。
12)Lazy class(冗余类)
13）Speculative Generality（夸夸其谈未来性）
其实这就是过度设计。我觉得实际中，要和懂业务了解业务的人多沟通，来规避这个问题。因为太防止“过度设计”，以后的修改也会变得很苦难。
14）Temporary Field（令人迷惑的暂时值域）
introduce Null object：感觉还不如抛exception
这个还真不太理解。
15）Message chains（过度耦合的消息链）
这种依赖，感觉上还是建立在对业务的认识上的。
16）Middle man
其实这一点，我还是不太认同。怎么说呢，有些时候中间人或者说中间人类的作用，就是降低耦合。
17）Inappropriate intimacy
这一些怎么说呢，完全是看个人的勤劳与否的程度的。
18）Alternative Classes with different Interfaces
19) incomplete library class
20)data classes
其实我这个不太同意。
21) Refuse Bequest
觉得这个应该从设计的高度来解决
22）Comments
个人理解了。
什么时候该重构--《重构》阅读笔记,布布扣,bubuko.com