首页 > 代码库 > 什么时候该重构--《重构》阅读笔记

什么时候该重构--《重构》阅读笔记

当出现以下问题的时候,就要开始重构代码。

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

      个人理解了。