代码重构的介绍

一、通过代码重构可以达到以下的目标

 

使代码更易为人所理解

Martin Flower在《重构》中有一句经典的话："任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。"对此，笔者感触很深，有些程序员总是能够快速编写出可运行的代码，但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这样的代码他会不会想当逃兵呢？

软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。

对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情！

 

 

帮助发现隐藏的代码缺陷

重构代码时逼迫你加深理解原先所写的代码。笔者常有写下程序后，却发生对自己的程序逻辑不甚理解的情景，曾为此惊悚过，后来发现这种症状居然是许多程序员常患的"感冒"。当你也发生这样的情形时，通过重构代码可以加深对原设计的理解，发现其中的问题和隐患，构建出更好的代码。

 

 

 

二、哪些情况需要考虑代码重构

 

臃肿的类: 类之所以会臃肿，是因为开发者缺乏对最基本的编码原则，即“单一职责原则”（SRP）的理解。这些类往往会变得很臃肿，是由于不同的且在功能上缺少关联的方法都放在了相同的类里面。

 

 

长方法: 方法之所以会变得很长主要是有以下几个原因：

        1、许多没有关联性的、功能复杂的模块的代码都放在相同的方法内。这主要是开发者缺乏SRP的概念。

        2、多种条件都放在同一个方法内，这在长方法内经常会发生的。这是由于缺乏McCabe代码复杂度和SRP的概念的比较。

 

 

大量的传参: 我经常遇到这几种情况，一些方法跟另一些方法进行交互，或者调用另一些方法的时候传入大量的参数。这就会出现如果更改了其中一个参数，就得在多个方法内进行更改。

 

 

模糊的方法名: 许多时候，以下取的方法名会影响代码的可读性和可理解性：

        1、模糊的不具有任何意义的方法名

        2、技术性的，却没有提及相关领域的名称

 

 

三、重构的方法

 

 

提取类/抽离方法

正如上面提到的，像“臃肿的类”（一个类提供了本该有几个类提供的功能）这种代码异味应该将原有类中的方法和属性移动到适当数目的新类中去。旧类中对应新类的方法和属性应该被移除。另外，有时候一些类过于臃肿是因为它包含了被其他类使用本应该是其他类的成员方法的成员方法。这些方法也应该被迁移到合适的类中。

 

 

提取方法

像上面提到的“过长的方法”这种代码异味可以通过从旧方法中提取代码到一个或多个新方法中消除。

 

 

分离条件

许多时候，一个方法很长是因为包含好几个分支语句（if-else）。这些分支条件可以被提取和移动到几个单独的方法中。这确实能大大改善代码可读性和可理解性。

 

 

用符号常量替换魔法数字

对于有意义的并且到处被使用的字面常量，应该为它们分配一个命名常量。这能大大增强代码可读性和可理解性。

 

 

重命名方法

正如上面提到的，模糊不清的方法名会影响代码的可使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称，来帮助开发者通过业务上下文更好地理解代码。这很需要技巧并且要求开发者与业务专家一起协作来理清代码需要满足的业务需求。有趣的是，这种重构方法看起来似乎非常容易理解，但是常常被许多开发者忽视，虽然在Eclipse这种IDE的refactor菜单项中经常出现这一项。

 

 

 

参考资料：    代码重构的方法     http://www.studyofnet.com/news/330.html