重构笔记——入门篇

本文是在学习中的总结，欢迎转载但请注明出处：http://blog.csdn.net/pistolove/article/details/41986271

      程序员经常会遇到晦涩难懂的代码，尤其是他人写的代码，可能是同事离职后转交给你维护的，也可能是项目遗留下来的。不管怎么样，当你被迫从一个2000行代码的类或一个500行代码的方法中去寻找并解决bug，我想大多数人都会头疼，对于没有一点注释的代码，甚至想死的心都有。这时候我们少不了会在心中默默诅咒写出这样代码的人。我想不管对于你还是我自己，当我们在开发的过程中，经常会抱以只要程序能正常运行就行，而不管代码是否整洁的心态。这样的做法其实是在坑自己，不要等到后续代码维护时再后悔当初没有把代码写好，那时再对代码进行修改，时间成本会很大，还不如从开始就保持代码的简短和整洁。我们就从重构开始吧。

何为重构？

      重构是对软件内部结构的一种调整，它不是改变代码的功能，而是在不改变软件可观察行为的前提下，提高其可理解性，降低修改成本。用比较通俗的话来说就是把代码从一个地方移动到另外一个地方，保持其简短、易读。

为何重构？

       如果没有重构，程序会逐渐腐败甚至变质。当我们只为了短期的目的或者在没有完全理解代码之前，就贸然修改代码，程序就会逐渐失去已有的结构，程序员则愈来愈难通过阅读源码来理解原来的设计。重构其实就像是在整理代码一样，你所做的就是让所有东西回到应处的位置上。就像我们收拾屋子一样，如果屋子天天都打扫，那么每天花几分钟就能保持干净；如果屋子一个月不打扫，你可以想想得花多久才能收拾完。代码结构的流失是具有累积性的，愈难看出代码所代表的设计意图，就愈难以保护其中的设计，于是设计就变腐败的愈快。如果能够经常地对代码进行重构，则可以帮助代码维持自己该有的状态。

何时重构？

     事不过三，三则重构。当我们第一次做一件事的时只管去做；第二次做类似的事就会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。

（1）当我们添加新功能时需要重构。

       最常见的重构时机是给软件添加新特性的时候。此时进行重构能够帮助我们理解需要修改的代码——这些代码可能是别人写的，也可能使我们自己写的，无论何时，只要我们能够理解代码所做的事，我们就有必要问自己：是否能对这段代码进行重构，使我能更快地理解它。之所这么做，部分原因是为了在下次看到这段代码时容易理解，但最主要的原因是：如果在前进的过程中把代码结构理清，就可以从中理解更多的东西。

（2）当我们修补错误时需要重构。

      调试过程中运用重构，大多是为了让代码更具有可读性。当我们看代码并努力去理解它的时候，我们使用重构帮助加深自己的理解。以这种程序来处理代码，常常能够帮助我们找出bug。可以这样想：如果收到一份错误报告，这就是需要重构的信号，因为代码还不够清晰——没有清晰到一眼就能看出bug。

（3）当我们复审代码时需要重构。

      重构可以帮助我们复审别人的代码。在开始重构前，我们可以先阅读代码，有一定程度的理解后，提出一些建议。一旦想到一些点子我们就可以考虑是否可以通过重构立即轻松地实现它们。如果可以，我们应该动手。这样做几次之后，我们把代码看得更清楚，提出更多恰当的建议。我们不必想象代码应该是什么样，我可以“看见”它是什么样子。

是什么让程序如此难以相与？

（1）难以阅读的程序，难以修改；

（2）逻辑重复的程序，难以修改；

（3）添加新的行为事需要修改已有代码的程序，难以修改；

（4）带复杂条件逻辑的程序，难以修改。

      本文介绍了重构的定义、重构的重要性、何时重构等。初步对重构进行了解，并提醒我们在开发过程中应该经常使用重构，以保持代码简短、整洁、易维护。希望能够对你有所帮助。