首页 > 代码库 > 什么时候该重构--《重构》阅读笔记
什么时候该重构--《重构》阅读笔记
当出现以下问题的时候,就要开始重构代码。
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
个人理解了。