重构一个函数的心得

重构一个函数的心得

重构不仅仅是一种思想，而且是一种技术。
    这里所说的“技术”强调的是重构的可操作性很强。经过实践我发现不仅仅根据代码的理解可以进行重构，也可以根据一些代码的形式去重构它。这是我原先忽略的，原先我只是凭感觉，根据代码的功能去把函数划分成块，再重构。这样做有一定的局限性，如果拿到手的是一段不熟悉的代码，就不能这样做了。于是我重新看了看书，发现认真的理解书上的重构法则，一步步地按照书上的方法做才是最安全、最准确的方法。所以我说，重构不仅仅是一种思想，也是一种技术，需要练习使用，熟了才能够掌握，而非像我以前那样大体理解一下就可以掌握了。这是我对重构的一个新的认识。

函数重构的一些思路总结（多丛形式上谈操作，多半是一家之言仅供参考）
一、看这个函数是否需要重构
判断依据
1）函数比较长，超过十行。我就想把它重构了。
2）一个函数好不好，我个人认为从形式上讲它的功能越简单，完成的事情越少越好。也就说它的功能比较“单纯”比较好。这样我感觉它在逻辑上最容易被理解、易读性最好。而判断这一条的一个办法就是，看这个函数函数体中改变了多少个变量。我感觉不管这个函数引入了多少参数，除了他调用的函数之外，它只改变或影响一个变量为最好。也就是说他的任务单一到只改变一个变量，这个变量或者是局部变量（最终把它return 给调用该函数的方法），或者是类的成员变量（经过函数的作用，改变了类成员变量，供下一个需要它作参数的方法使用）。这样我拿到函数就会看一下，他其中改变了几个变量，如果不止一个我就多半要重构它了（当然这不是绝对，还要从功能上去综合考虑）。

二、从功能上划分重构的组成函数
重构的很重要一个功能就是为了优化代码，使之易读性更好。这个时候按照语义功能划分重构的函数是首先要考虑的我认为。因为按照自己的理解把函数代码划分为几块后，代码对于重构者来说是容易被理解的、易读性是最好的。如果重构者功力深，它的划分比较接近大家的理解，那么按这样思路重构的代码易读性一定也好。这里有个办法可操作，我通常是上来按照原代码的注释，一条注释下面的一段代码划分为一块。用#region+[试图重构的函数名称]和#endregion来括起来。这样适合整体搬移。当你把整个函数都这样括起来之后，代码的思路也就很清晰了。然后就可以把其它的块收缩起来，只展开当前需要重构的那部分来集中精力重构它。

三、针对一对#region里的代码重构
1）可以重复二的办法对#region里面的代码进行功能上的进一步划分。直到你用一中的两个原则去评判这块代码看上去是好的。
2）利用重构的方法将#region里面的代码重构。

四、对于很难理解的函数代码的重构
   当你对于要重构的函数思路不了解的时候，也就是说你无法开始从功能上去划分#region块的时候，你就该更多的从代码的形式上去考虑重构。
1）根据局部变量的作用域决定是否替换掉它
   按照我的一中提到的判断函数好坏的原则--一个好的函数应该最好只修改或影响一个变量。我们应该首先看局部变量的作用域。
通常我是先找到每一个局部变量的声明，然后屏蔽掉它，编译后看他所产成的错误。以此来看变量的作用域。如果它从第一次赋值后没有被改变过，我们就把它Replace Temp with Query。如果它被改变了，那么就用#region把从他的声明到他的改变后第一次被引用括起来。把这部分作为重构的研究对象。

 

去除循环中的flag标志变量
1、flag一定能被去除
2、如果在循环中flag被再次赋值，并被传出while循环之外，则它可以被return [再次被赋的值]所替代。
3、否则可以使用break替换。

在对象间搬移特性
基本步骤：
1、封装--将要搬移的特性封装（如果是函数则把函数体视为field，函数名称为对函数体的封装）
2、搬移--将被封装的特性（包括函数体）搬移到另一个对象中（如果是函数则要在target对象中新建函数声明）。
3、委托--将搬移到另个一个对象中的特性在封装函数中委托
4、去掉委托
注：每步之间都经过运行测试，通过后运行下一步

搬移顺序：
先搬移field再搬移方法。在搬移的方法中遇到其它需要搬移的field，先搬移它再搬移所在的函数
封装

具体步骤：
对于一个field，执行到3后，利用查找标记工具，找到所有调用该封装函数的所有函数。在函数中发现类成员变量就试图把它搬移--重复执行1234。

当发现当前的程序整体实现不佳，想用其他方法重构它。应该先将函数搬移到不同的类中，简化当前接口。然后再试图替换实现。

----未完