《重构》学习笔记二

    何谓重构，对它熟悉后估计理解都不用，作者说了两个概念，动词和名词，意思都差不多，无法就是通过调整软件内部的结构来达到想要的样子。

 

 

 

 

 

一、为何重构

    改进软件设计 :

    不管开始的时候设计是多么好的一个软件，随着越来越多的修改，之前的设计也会被埋在代码堆里面。重构能够整理之前的设计，甚至改变原来设计不足的地方。

 

    使软件更易被理解 :

    代码总会给其他开发人员看或是浏览其他开发人员的代码，甚至自己回头看自己以前的代码。做开发的都有这样的经历，看别人的代码，不是一般的头疼。为了大家，为了项目，我们应该重构代码，使其容易理解。在看别人代码的时候，重构之，也可以加快自己对代码的理解。我以前都是傻呼呼的看别人的垃圾代码，一直在抱怨，可是从来没动手重构过。看了这个后，回去试试了，发现的确理解代码逻辑的速度快乐好多。个人觉得糟糕的代码不是看不都，只是我们大脑无法记住那复杂的东西（大脑堆栈不够用），而那些优秀的代码，从代码的结构上就开始帮助阅读者理解。

 

    帮组找 BUG ：

    这个个人感觉可以参考上面那条。容易看懂程序，自然容易发现 BUG

 

    提高编程速度：

    单从光写代码角度来看，按业务写一篇代码是最快的，为了重构，一个对重构不熟练的我，需要多话三分之一的时间在重构上。不过随着需求的变化等，会发现那些大段不知所云的代码的确十分影响进度，而且很难修改或是加入好的设计。

 

二、何时重构

    三次法则 :

    用我初中语文老师的话，好事不过三，更何况坏事，要一而再再而三的忍受无法入目的代码，也是一种本事。

 

    添加功能时重构：

    很容易理解

 

    修补错误时重构：

    同上

 

    复审代码时重构：

    从来没在大公司呆过，所以没经历过代码的复审，看作者的意思是由专人对一部分代码进行检查。

 

Kent Beck 的 Why refactoring works 中说的比较贴切，大部分时间我们只知道现在要做什么，而很难预知未来需要做什么，这样我们无法为未来留下更多的余地。所以，等到明天变今天的时候我们去重构，以求容易修改。

 

三、怎么向经理说？ 是个很严重的问题，不过是个情商活，我就不多说了，借口千千万万，一个就足够。

 

这里作者介绍了 Kent Beck 关于中间层的论述，我没搞懂，感觉理解很别扭（我阅读能力太差了吧），有时间看了英语原文在补上。

 

四、重构的难题

    数据库重构： 我现在就遇到这个问题，做数据库表结构的重新设计和数据的迁移时，真的无从下手啊，经验少了点，唉。作者说在对象模型和数据库模型中间加入个分隔层。没试验过，作者也没说怎么实现，难道像 hibernate 那样。

 

    修改接口：

    万恶的 EJB ，对远程调用提供接口，害的我都没法改接口。作者说的保留原接口，实现新接口的方法是个中庸之道，在无法同步修改的情况下，这个方法很好。原来的旧接口直接用适配模式或是装饰模式，用新的接口实现老接口的功能。

 

    难以通过重构来改动的设计模式：

    系统的大范围模式变动，估计不是重构能办得到的。

 

五、何时不该重构

    作者之说了在赶进度的时候（恐怕这个时间在项目开发中占大部分），其他未知。

 

六、重构与设计

    这个部分主要将了过度的预先设计和完全不进行预先设计两个极端的存在。过度的预先设计，最求在动手写代码前为整个系统包括未来的扩展和变化都设计好；完全不进行预先设计则是上来就动手写代码，随遇而安，后期在整理设计。

低级程序员就是浑浑噩噩写程序；进阶了，发现设计很重要，就开始拼命的实现做完美的设计（我现在就这个阶段，悲哀，被一语道破啊）。作者的观点就是要预先设计，但不能过度，开发也要不断重构。结合上面的“今天要做什么”和“明天要做什么”，个人觉得是先要为当前的做设计，等后面的变动过来后，在做合理的变动（包括重构和修改原有设计）。 Ron Jeffries 提供的例子很好的说明了空谈主义的悲剧。

 

七、重构和性能

    一句话，对于那些对性能要求不是很苛刻的系统，其他都是先编码 + 重构，完了在整个系统统一优化性能。