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

 

重构——改善现有代码的设计

 读书笔记

 

为什么重构？

       相信任何程序员，无论技术拙劣或高超，都可以写出机器理解的代码。但是不是所有的程序员，无论技术拙劣或高超，都可以写出其他人（包括他自己）可以轻易看懂的代码，尤其是离第一次写该代码已经过去一个月甚至一年。重构技术的给我们代来的第一个好处就是他是我们的代码条理清晰，简明易读。于此同时，重构技术借用OO原则，将强代码的扩展性和灵活性，使得日后添加新功能更加轻松容易。

更重要的是，重构加快了我们的开发进度。在软件开发过程中，我们每天应该关注两件事情，“今天应该做什么”和“明天应该做什么”。大多数时候，无论是修改BUG还是添加新功能，我们都是关注今天应该完成的事情，忽略了今天已经做的事情对明天应该做的事情的影响。这样，今天虽然完成任务，但是明天无法完成，同时导致后天也无法完成······就这样，造成了恶性循环，得不偿失。

重构是改变这种束缚之道。今天发现昨天做的事情无法继续，重构之。明天也许发现见天的事情很幼稚，重构之。反正你可以在需要修改的时候进行重构过程。

重构虽然在短期内放慢了我们的开发速度，但是重长远角度来看，我们会更容易添加新功能，更容易对现有的代码进行维护。从而弥补先前的损失。正所谓磨刀不误砍柴工吗！

通过重构，可以去除我们代码中的一些坏味道（bad smell），因此，积极进取的程序员应该对该技术产生兴趣，使用该技术。这就是为什么我们要用重构。

 

如何重构？

重构一般和添加新功能同时交替进行。在进行这两项活动的时候，就好像戴上两顶帽子，“重构”不会添加删除添加软件功能，对于用户而言，重构是透明的。“添加新功能”就不要过于担心可扩展性和灵活性，首要任务是添加新功能。如果在重构时，发现需要添加的功能，可以记下来，稍后再添加新功能。添加新功能的时候也是一样。

软件设计与重构可以互补。软件设计可以使我们编程时思考更快，但是起中充满了小漏洞，这些漏洞需要重构来弥补。有人把程序员与民工作比喻。程序员只需要照着设计的图纸编码就可以。但我个人并不这样认为，软件的开发与现实世界建筑建设不同，没有精确的数学公式和物理定理可以借鉴，可塑性很大。现实世界的建筑图纸可以精确的设计出所有的管道，走廊布局，门窗结构，民工只需要按照图纸做就可以。但是软件的设计往往不可能一步到位，经常由于需求的变更而改变，所以需要对程序员有较高要求，能够应付这种改变，或者预知这种改变，事先做好准备。重构就可以帮助我们预测这种改变，做到未雨绸缪。

以前的开发，在设计上实用的经历很多。因为总是希望找到一个灵活的设计方案，以应变日后的各种变化。这样往往增加的程序的复杂度和可维护性。但是，最后发现这些灵活性大多没有必要，到头来白忙活。有了重构技术，我们在设计时不需要投入过多的精力，开始只用找到一个恰当的解决方案，如果日后发现该方案不能满足要求，重构之。并且，随着时间的流逝，我们对系统的理解日益加强，我们会更容易的找到灵活的方案。

 

合适使用重构？

1）              修改Bugs：当你发现代码晦涩难以理解时，你需要重构。

2）              添加新功能：当你发现新功能不容易加入，或是加入新功能后   模块的耦合加大，你需要重构

重构没有固定的时间周期，当你发现需要重构时，就放开手去重构。但是有的时机，重构也不太适宜，如：

1）              项目快到期了，重构的长远效应体现不出来。

2）              软件大部分不能运转。

重构时，不要太注重性能优化，因为此时不是考虑性能优化的时段。你同时应该只把注意力放在一个目标上。等到性能优化时，你在着重考虑该问题。并且，一个项目需要优化的地方只有20%是性能的瓶颈，其余的80%无伤大雅。所以你在总够过程重遇到需要性能优化的地方可能并不会对系统的总体性能造成太大的消耗。

 

 

上面讲了这么多重构的好处，但都是站在森林100里外欣赏森林。接下来，我将详细的总结一下重构的细节，仔细的欣赏一下重构森林里的美妙风景。

      Martin Fowler大师和Kent Beck大师在谈论如何找到既有代码中需要重构之处时，使用了一个很形象的比喻——坏味道（Bad Smells in Code）。需要重构的地方是散发着浓烈的坏味道的，如果不用重构芳香剂去除之，将会使你的代码慢慢腐败变质，遗臭万年。下面，我就来谈谈这些坏味道。

 

Bad Smells List：

1.       Duplicated Code（重复代码）：重复代码是万恶之源。重复的代码便显出了设计者的设计不够完善，无法将这些重复的代码放到一个类中安家，而是将他们分散在系统中的许多地方。这样，一旦你需要修改这些地方中的一个，你就需要找到系统中的其他地方，将他们全部修改。这种情况在大型程序中，将会给维护人员带来噩梦。最重要的还不仅仅是代码级的糟糕表现，而是设计级别的不协调。因为没有遵循DRY（Don’t Repeat Yourself,不要重复你自己）。

2.       Long Method（过长方法）：经验表明，过长的方法体（几百行以上）表明你的代码中存在着严重的OP（Procedure-Oriented，面向过程）编程迹象。所以，你需要重新省视你的代码，抽象出可以重用的代码段，实用Extract Method重构技巧给他们安个家。在过长的方法中，经常出现很大的if—else或switch，这时，你就需要考虑用Replace Nested Conditional with Polymorphism来去除这些巨大的条件选择。总之，作为一个纯粹的OO设计，过长的方法几乎是不会出现的，也不应该出现。

3.       Large Class（过大类）：