代码重构

一、什么是重构

重构（Refactoring）就是在不改变软件现有功能的基础上（这是前提），通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

好的代码里一般会定义大量的类、接口、方法，类与类，类与接口之间很多是继承和实现的关系，方法的代码行数很少，超过20行代码的方法不多，看这样的代码感觉最多的就是方法之间的调来调去。 

二、为什么要重构（重构的好处）

对软件的生命造成威胁的因素只有一个：需求的变更。一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。在这种情况下，软件必须相应的改变。

通过重构可以达到以下的目标：

1）降低代码冗余度，增强代码的可复用性。

2）增强软件后期的可扩展性。

　　 3）持续偏纠和改进软件设计
　　 重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。

　　4）使代码更易为人所理解
　　软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。
　　对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情！

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

　　6）从长远来看，有助于提高编程效率
　　当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错了方法，拙劣的设计往往导致臃肿的编码。
　　改善设计、提高可读性、减少缺陷都是为了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的。

三、什么情况下重构代码

1）方法名不同但功能相似

重命名：对类，接口，方法，属性等重命名，以使得更易理解

如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能，你会发现往往是因为开发团队协调不够造成的。

2）代码中存在重复的代码

抽取代码：将方法内的一段代码抽取为另一个方法，以使得该段代码可以被其他方法调用，这是重构中很重要很常用的，此举可以极大的精炼代码，减少方法的代码行数

如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。

3）过大的类和过长的方法

过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方法时，需要想办法将其划分为多个小方法，以便于分而治之。

4）牵一发而需要动全身的修改
　　 当你发现修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。

iOS开发中可以根据单独的控件来进行代码重构，比如在iOS中一些控件（UIButton、UISearchBar等）就可以重构出一个单独的类，在别的类中就可以引入该类的头文件并且调用其中的方法即可。

iOS开发中也可以按照分类的思想来进行代码重构，比如有些地方要用到拉伸的背景图片，就可以根据Image来写一个类，里面写一个resizeImageWithName：方法，如果别的类需要用拉伸图片就可以引入该类的头文件并且调用resizeImageWithName：方法；相同的还有密码MD5算法、解档归档等。

5）缺少必要的注释

人的记忆曲线下降的坡度是陡得吓人的，当过了一段时间后再回头补注释时，很容易发生"提笔忘字，愈言且止"的情形。Github上一些牛逼的第三方开源类库的注释也是相当的详尽，就像一篇文章。

个人在iOS开发过程中用的最多的是2、4。