码代码已经有些年头了，对代码的书写也有一些自己的认识。至于什么是好代码，什么样的代码才是别人喜欢的代码？我相信每个码农心中都有自己的理解，我在这里就不多废话了。
其实在实际的项目开发工作中，我们写的代码绝大部分都是其他同事在后期维护，真正自己维护自己的代码的人不多。那么高质量的代码就显得尤为重要了，若不是心中在犯什么嘀咕，那么我们就应该有义务和责任去设计好我们的代码。
前期能够预防的就只有我们做好前期的框架、代码设计，后期的只能通过重构，重构，再重构的方式来改善代码的设计，因此了解一些常用的重构技巧是每一个要久经沙场的码农所应该具备的技能，因此后续我会带着大家分享一些重构的技能，欢迎大家与我一起讨论与分享！
1. 什么是重构？
名词解释：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
动词解释：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
重构的目的是使软件更容易被理解和修改，并不会改变软件的可观察行为。重构之后软件功能不会发生任何变化，对于任何用户直观的观察是：他们都不知道程序内部已经发生了变化。
2. 为什么要重构？
重构不是万能的，他并不能直接的解决软件在功能上的问题。重构只是一个工具，帮助你管理好代码的工具，帮助你在下次修改它时能够更加高效快捷。
①重构改进软件设计：往往程序设计的初期，设计方案不可能预测到系统几年甚至几个月以后的变化，那么一段时间以后的系统不可能就直接推翻重新分析需求，重新编码。这种情况我相信大家都是不喜欢的，即使你喜欢，公司的老板也不会喜欢的，这样势必会造成程序的开发成本太高。那么贸然的修改原来的代码，没有经过一个系统的分析，必然会逐渐的失去系统原有的设计框架和结构，后期的开发人员会越来越难于维护这个系统，其中的功能设计也就越难于看护了。因此长期的重构工作是每一个程序员势必应该具备的技能。
②重构使代码更容易理解：前人写的代码难读难懂；自己前期书写的代码难读难懂。在这些情况下，我想大家都应该有一颗想去修改这些“怪味”的冲动吧。
③重构帮助发现问题：确切点说是重构有时候能够帮助我们发现系统的BUG。尤其是在前期局部的代码修改往往只注重了代码的局部效果，而忽视了程序的整体功能，而重构往往又需要一个对系统的整体分析，在系统分析的时候能够发现一些平常所忽视的编码造成的bug。
④重构能够帮助提高编程效率：好的框架，好的代码结构，好的设计能够在编码的时候提高编码人的心情，心情美丽了，做事效率自然就高了。
3. 什么时候重构？
大家都知道“坏味道”的代码需要重构，那么我们一般在哪些情况下才需要重构呢？重构是不是需要单独的抽一两天，一两周出来专门从事这个工作呢？答案当然是NO NO NO NO~
首先代码的重构不需要我们单独为之抽出具体的时间周期性的处理，尽管重构的工作很重要，在我的理解是我们需要把重构的习惯嵌入到我们的日常开发工作中去。在《重构-改善既有代码的设计》一书中有提到三次法则，事不过三，三则重构。
第一次：设计之初，尽管放手一搏，尽管去做；
第二次：做类似的事情，想同的工作，内心可能有些反感；（很多牛人不愿意给一个入门者讲一些入门的知识是一个道理）
第三次：再做类似的事情。此时你应该重构了！！！
一般我们会在以下三种背景情况下会选择重构：
①添加功能时：添加新功能时，可能前期的设计满足不了当前的扩展需求，那么你就应该在不改变软件原有功能的前提下，重构之，再添加新功能。
②修补错误时：修改bug的时候你发现这里的设计不完美（强迫症患者）或者这个bug明显就是设计缺陷导致的，那么这样的情况你也需要重构。
③复审代码时：我相信大家很多时候都有代码检视的说法，这个动作在我们的日常开发工作中应该要一直做下去，还要做好，这是看护我们代码质量很重要的一道关卡。在代码检视的过程中，旁观者很容易能够看清程序的缺陷。因为我们在编码的时候很容易以程序理解的方式去编写程序，过于聚焦某一个细节上的处理而忽视了程序的主体，这一点在初级程序员身上体现的尤为明显，程序的抽象，归纳过程很重要，通过抽象的编程才能编写出高质量、复用强，可读性强的代码。
以上就是我今天要与大家分享的知识点，如果你对代码质量重构有兴趣，请记得关注我的后续重构主题的分享.....
以下是代码重构技巧列表：
1.条件表达式重构
如果你觉得本博文对你有所帮助，请记得点击右下方的"推荐"哦，么么哒...
转载请注明出处:http://www.cnblogs.com/liushaofeng89/p/4993329.html