1.概念：
重构（Refactoring）就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。
2.为什么要重构？
因为通过重构可以达到以下的目标：
(1)持续偏纠和改进软件设计
重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。</td> </tr> <tr> <td height="20" colspan="2"> (2) 使代码更易为人所理解
Martin Flower在《重构》中有一句经典的话："任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。"对此，笔者感触很深，有些程序员总是能够快速编写出可运行的代码，但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这样的代码他会不会想当逃兵呢？
软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。
对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情！
(3) 帮助发现隐藏的代码缺陷
孔子说过：温故而知新。重构代码时逼迫你加深理解原先所写的代码。笔者常有写下程序后，却发生对自己的程序逻辑不甚理解的情景，曾为此惊悚过，后来发现这种症状居然是许多程序员常患的"感冒"。当你也发生这样的情形时，通过重构代码可以加深对原设计的理解，发现其中的问题和隐患，构建出更好的代码。
(4) 从长远来看，有助于提高编程效率
当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错了方法，拙劣的设计往往导致臃肿的编码。
改善设计、提高可读性、减少缺陷都是为了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的。
3.那么我们究竟如何去重构？
这个问题是个很难全面去把握的问题，为什么这样说呢？可以大致从三个方面来理解
3.1重构与设计
重构可以从很大程度上去扶助设计，通常情况下我们的设计不是能贯穿我们软件开发的全过程的，在这个过程中，我们的需求变更的可能性非常大，当需求变了，设计也得变，但是我们已有的实现怎么办？全部废除?显然不能！这时候就要依靠重构来解决这种矛盾。
3.2重构与性能
关于重构，有一个常被提出的问题：它对程序的性能将造成怎样的影响？为了让软件易于理解，你常会作出一些使程序运行变慢的修改。这是个重要的问题。我并不赞成为了提高设计的纯洁性或把希望寄托于更快的硬件身上，而忽略了程序性能。已经有很多软件因为速度太慢而被用户拒绝，日益提高的机器速度亦只不过略微放宽了速度方面的限制而已。但是，换个角度说，虽然重构必然会使软件运行更慢，但它也使软件的性能优化更易进行。关键在于自己的理解，当你拥有了重构的经验，你也就有能力在重构的基础上来改进程序的性能。
3.3重构与模式
那么真正要实现重构时，我们有哪些具体的方法呢？可以这样说，重构的准则由很多条，见《重构》这本书。但它不是最终的标准，因为你要是完全按照它的标准来执行，那你也就等于不会重构，重构是一种武器，而真正运用武器的高手是没有武器胜有武器。只有根据实际的需要，凭借一定的思想，才能实现符合实际的重构，我们不能被一些固定的模式套牢了，这样你的程序会很僵化。究竟如何把握这个度，需要大家去总结。
3.4重构与思想
要想实现一个好的重构，不是重构本身，而是我们在写代码的时候，思想当中时刻有它的位置存在！非常重要！如果你本身就没想着要去重构，那么就是有再好的模式供你调用又怎么样？就是有了好的模式，你不能根据实际的需要去融会贯通，那你做出来的重构有意义么？大家共同思考一下吧。 </td> </tr> </table> </td> </tr> <tr>
↑返回目录
前一篇: 模仿Dos界面的程序
后一篇: 深入浅出面向对象的复用