本文是在学习中的总结，欢迎转载但请注明出处：http://write.blog.csdn.net/postedit/41986271
程序猿常常会遇到晦涩难懂的代码，尤其是他人写的代码，可能是同事离职后转交给你维护的，也可能是项目遗留下来的。无论怎么样，当你被迫从一个2000行代码的类或一个500行代码的方法中去寻找并解决bug，我想大多数人都会头疼，对于没有一点凝视的代码，甚至想死的心都有。这时候我们少不了会在心中默默诅咒写出这样代码的人。我想无论对于你还是我自己，当我们在开发的过程中，常常会抱以仅仅要程序能正常执行即可，而无论代码是否整洁的心态。这种做法事实上是在坑自己，不要等到兴许代码维护时再懊悔当初没有把代码写好，那时再对代码进行改动，时间成本会非常大，还不如从開始就保持代码的简短和整洁。我们就从重构開始吧。
何为重构？
重构是对软件内部结构的一种调整，它不是改变代码的功能，而是在不改变软件可观察行为的前提下，提高其可理解性，减少改动成本。用比較通俗的话来说就是把代码从一个地方移动到另外一个地方，保持其简短、易读。
为何重构？
假设没有重构，程序会逐渐腐败甚至变质。当我们仅仅为了短期的目的或者在没有全然理解代码之前，就贸然改动代码，程序就会逐渐失去已有的结构，程序猿则愈来愈难通过阅读源代码来理解原来的设计。重构事实上就像是在整理代码一样，你所做的就是让全部东西回到应处的位置上。就像我们收拾屋子一样，假设屋子天天都打扫，那么每天花几分钟就能保持干净；假设屋子一个月不打扫，你能够想想得花多久才干收拾完。代码结构的流失是具有累积性的，愈难看出代码所代表的设计意图，就愈难以保护当中的设计，于是设计就变腐败的愈快。假设能够常常地对代码进行重构，则能够帮助代码维持自己该有的状态。
何时重构？
事只是三，三则重构。当我们第一次做一件事的时仅仅管去做；第二次做类似的事就会产生反感，但不管怎样还是能够去做；第三次再做类似的事，你就应该重构。
（1）当我们加入新功能时须要重构。
最常见的重构时机是给软件加入新特性的时候。此时进行重构可以帮助我们理解须要改动的代码——这些代码可能是别人写的，也可能使我们自己写的，不管何时，仅仅要我们可以理解代码所做的事，我们就有必要问自己：能否对这段代码进行重构，使我能更快地理解它。之所这么做，部分原因是为了在下次看到这段代码时easy理解，但最基本的原因是：假设在前进的过程中把代码结构理清，就行从中理解很多其它的东西。
（2）当我们修补错误时须要重构。
调试过程中运用重构，大多是为了让代码更具有可读性。当我们看代码并努力去理解它的时候，我们使用重构帮助加深自己的理解。以这样的程序来处理代码，经常可以帮助我们找出bug。可以这样想：假设收到一份错误报告，这就是须要重构的信号，由于代码还不够清晰——没有清晰到一眼就能看出bug。
（3）当我们复审代码时须要重构。
重构能够帮助我们复审别人的代码。在開始重构前，我们能够先阅读代码，有一定程度的理解后，提出一些建议。一旦想到一些点子我们就能够考虑能否够通过重构马上轻松地实现它们。假设能够，我们应该动手。这样做几次之后，我们把代码看得更清楚，提出很多其它恰当的建议。我们不必想象代码应该是什么样，我能够“看见”它是什么样子。
是什么让程序如此难以相与？
（1）难以阅读的程序，难以改动；
（2）逻辑反复的程序，难以改动；
（3）加入新的行为事须要改动已有代码的程序，难以改动；
（4）带复杂条件逻辑的程序，难以改动。
本文介绍了重构的定义、重构的重要性、何时重构等。初步对重构进行了解，并提醒我们在开发过程中应该常常使用重构，以保持代码简短、整洁、易维护。希望可以对你有所帮助。