重构 — 作用
重构，绝对是软件开发写程序过程中最重要的事之一。那么什么是重构，如何解释重构。名词：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。动词：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
重构不只可以改善既有的设计结构，还可以帮助我们理解原来很难理解的流程。比如一个复杂的条件表达式，我们可能需要很久才能看明白这个表达式的作用，还可能看了好久终于看明白了，过了没多长时间又忘了，现在还要从头看，如果我们把这个表达式运用Extract Method抽象出来，并起一个易于理解的名字，如果函数名字起得好，下次当我们再看到这段代码时，不用看逻辑我们就知道这个函数是做什么的。
如果对这个函数内所有难于理解的地方我们做了适当的重构，把每个细小的逻辑抽象成一个小函数并起一个容易理解的名字，当我们看代码时就有可能像看注释一样，不用再像以前一样通过看代码的实现来猜测这段代码到底是做什么的，我一直坚持和秉持这个观点：好的代码胜过注释，毕竟注释还是有可能更新不及时的，不及时最新的注释容易更其他人带来更多的理解上的困惑。
此外重构可以使我们增加对代码和业务逻辑功能的理解，从而帮助我们找到Bug；重构可以帮助我们提高编程速度，即重构改善了程序结构设计，并且因为重构的可扩展性使添加新功能变得更快更容易。
重构 — 时机
理解了重构的意义和作用，那么我们何时开始重构呢？笔者一直坚持这种观点：重构是一个持续的系统性的工程，它是贯穿于整个软件开发过程中，我们无需专门的挑出时间进行重构，重构应该随时随地的进行，即遵循三次法则：事不过三，三则重构。这个准则表达的意思是：第一次去实现一个功能尽管去做，但是第二次做类似的功能设计时会产生反感，但是还是会去做，第三次还是实现类似的功能做同样的事情，那你就应该去重构。三次准则比较抽象，那么对应到我们具体的软件开发流程中，一般可以在这三个时机去进行：
（1） 当添加新功能时如果不是特别容易，可以通过重构使添加特性和新功能变得更容易。在添加新功能的时候，我们就先清理这个功能所需要的代码。花一点时间，用滴水穿石的方法逐渐清理代码，随着时间的推移，我们的代码就会越来越干净，开发速度也会越来越快。
（2） 修改Bug的时候去重构，比如你在查找定位Bug的过程中，发现以前自己的代码或者别人的代码因为设计缺陷比如可扩展性、健壮性比较差造成的，那么此时就是一个比较好的重构时机。可能这个时候很多同学就有疑问了，认为我开发要赶进度，没有时间去重构，或者认为我打过补丁把Bug解决不就行了，不需要去重构。根据笔者之前多年的经验得出的结论：遇到即要解决即那就是每遇到一个问题，就马上解决它，而不是选择绕过它。完善当前正在使用的代码，那些还没有遇到的问题，就先不要理它。在当前前进的道路上，清除所有障碍，以后你肯定还会再一次走这条路，下次来到这里的时候你会发现路上不再有障碍。
软件开发就是这样。或许解决这个问题需要你多花一点时间。但是从长远来看，它会帮你节省下更多的时间。也就是重构是个循序渐进的过程，经过一段时间之后，你会发现之前所有的技术债务会逐步都不见了，所有的坑相继都被填平了。这种循序渐进的代码重构的好处开始显现，编程的速度明显会加快。
（3）Code Review时去重构，很多公司研发团队都会有定期的Code Review,这种活动的好处多多，比如有助于在开发团队中传播知识进行技术分享，有助于让较有经验的开发者把知识传递给欠缺经验的人，并帮助更多的人对软件的其他业务模块更加熟悉从而实现跨模块的迭代开发。Code Review可以让更多的人有机会对自己提出更多优秀好的建议。同时重构可以帮助审查别人的代码，因为在重构前，你需要先阅读代码得到一定程度的理解和熟悉，从而提出一些建议和好的idea,并考虑是否可以通过重构快速实现自己的好想法，最终通过重构实践你会得到更多的成就感满足感。为了使审查代码的工作变得高效有作用，据我以前的经验，我建议一个审查者和一个原作者进行合作，审查者提出修改建议，然后两人共同判断这些修改是否能够通过重构轻松实现，如果修改成本比较低，就在Review的过程中一起着手修改。
如果是比较大型比较复杂的设计复查审核工作，建议原作者使用UML类序列图、时间序列图、流程图去向审查者展现设计的具体实现细节，在整个Code Review中，审查者可以提出自己的建议或者修改意见。在这种情景下，审查者一般由团队里面比较资深的工程师、架构师、技术专家等成员组成。
关于Code Review的形式，还可以采取极限编程中的“结对编程”形式。这种形式可以采取两个人位置坐在一起去审查代码，可以采取两个平台比如IOS 和android 的开发人员一起去审查，或者经验资深的和经验不资深的人员一起搭配去审查。
重构的这三个时机要把握好原则，即什么时候不应该重构，比如有时候既有代码实现太混乱啦，重构它还不如重新写一个来得简；此外，如果你的项目已经进入了尾期，此时也应该避免重构，这时机应该尽可能以保持软件的稳定性为主。
理解了重构是做什么，重构的作用，为什么要重构，以及重构的时机，我们对重构有了初步认识，接下来笔者重点篇幅来讲解如何使用重构技巧去优化代码质量达成Clean Code .
重构技巧 — 函数重构
重构的源头一切从重构函数开始，掌握函数重构技巧是重构过程中很关键的一步，接下来我们来探讨下函数重构有那些实用技巧。
重命名函数（Rename Function Name） : Clean Code要求定义的变量和函数名可读性要强，从名字就可以知道这个变量和函数去做什么事情，所以好的可读性强的函数名称很重要，特别是有助于理解比较复杂的业务逻辑。
移除参数（Remove Parameter）: 当函数不再需要某个参数时，要果断移除，不要为了某个未知需求预留参数，过多的参数会给使用者带来参数困扰。
将查询函数和修改函数分离：如果某个函数既返回对象值，又修改对象状态。这时候应该建立两个不同的函数，其中一个负责查询，另一个负责修改。如果查询函数只是简单的返回一个值而没有副作用，就可以无限次的调用查询函数。对于复杂的计算也可以缓存结果。
令函数携带参数：如果若干函数做了类似的工作，只是少数几个值不同导致行为略有不同，合并这些函数，以参数来表达不同的值。
以明确函数取代参数：有一个函数其中的逻辑完全取决于参数值而采取不同行为，针对该参数的每一个可能值建立一个单独的函数。
保持对象完整性：如果你需要从某个对象取若干值，作为函数的多个参数传进去，特别是需要传入较多参数比如5个参数或者更多参数时，这种情况建议直接将这个对象直接传入作为函数参数，这样既可以减少参数的个数，增加了对象间的信赖性，而且这样被调用者需要这个对象的其他属性时可以不用人为的再去修改函数参数。
以函数取代参数：对象调用某个函数，并将所得结果作为参数传递给另外一个函数，而那个函数本身也能够调用前一个函数，直接让那个函数调用就行，可以直接去除那个参数，从而减少参数个数。
引入参数对象：某些参数总是同时出现，新建一个对象取代这些参数，不但可以减少参数个数，而且也许还有一些参数可以迁移到新建的参数类中，增加类的参数扩展性。
移除设值函数（Setting Method）：如果类中的某个字段应该在对象创建时赋值，此后就不再改变，这种情景下就不需要添加Setting method。
隐藏函数：如果有一个函数从来没有被其他类有用到，或者是本来被用到，但随着类动态添加接口或者需求变更，之后就使用不到了，那么需要隐藏这个函数，也就是减小作用域。
以工厂函数取代构造函数：如果你希望创建对象时候不仅仅做简单的构建动作，最显而易见的动机就是派生子类时根据类型码创建不同的子类，或者控制类的实例个数。
重构技巧 — 条件表达式
分解条件表达式：如果有一个复杂的条件语句，if/else语句的段落逻辑提取成一个函数。
合并条件表达式：一系列条件测试，都得到相同的测试结果，可以将这些测试表达式合并成成一个，并将合并后的表达式提炼成一个独立函数，如果这些条件测试是相互独立不相关的，就不要合并。
合并重复的条件片段：在条件表达式的每个分支上有着相同的一段代码，把这段代码迁移到表达式之外。
移除控制标记：不必遵循单一出口的原则，不用通过控制标记来决定是否退出循环或者跳过函数剩下的操作，直接break或者return。
以卫语句替代嵌套条件表达式：条件表达式通常有两种表现形式，一：所有分支都属于正常行为；二：只有一种是正常行为，其他都是不常见的情况。对于一的情况，应该使用if/else条件表达式；对于二这种情况，如果某个条件不常见，应该单独检查条件并在该条件为真时立即从函数返回，这样的单独检查常常被称为卫语句。
以多态取代条件表达式：如果有个条件表达式根据对象类型的不同选择而选择不同的行为，将条件表达式的每个分支放进一个子类内的覆写函数中，将原始函数声明为抽象函数。
引入Null对象：当执行一些操作时，需要再三检查某对象是否为NULL，可以专门新建一个NULL对象，让相应函数执行原来检查条件为NULL时要执行的动作，除NULL对象外，对特殊情况还可以有Special对象，这类对象一般是Singleton.
引入断言：程序状态的一种假设
以MAP取代条件表达式：通过HashMap的Key-Value键值对优化条件表达式，条件表达式的判断条件作为key值，value值存储条件表达式的返回值。
通过反射取代条件表达式：通过动态反射原理