原始作者不明，出处不明。
当我第一次知道“重构”这个词时，直觉告诉我，这是一项非常重要的技术。因为程序员写代码，虽然越来越趋于工程化，但就程序本身，还是有艺术之美的存在的。曹雪芹先生写《红楼梦》，“批阅十载，增删五次”，留下了恢弘巨著；要写出一个比较优美经典的程序，同样需要精雕细琢，提高其质量，这就是重构。
我手头的这本《重构》，是Martin Fowler主笔的，另外有四位重构技术的专家级人物Kent Beck, John Brant, William Opdyke, Don Roberts也参与了最后几章的编写。这是一本与《设计模式》齐名的经典之作。Martin Fowler，除了是对象技术方面的专家外，还是UML和模式方面的专家。他撰写的Analysis Patterns、UML Distilled、Patterns of EntERPrise Application Architecture和Planning Extreme Programming几本书也广受赞誉。中国电力出版社出版的这本书，是由著名的侯捷先生和熊节先生翻译的。侯捷和熊节先生的翻译非常的到位，并保留了一些大家都能理解的、翻译了反而不通顺的英语单词（这好像是侯捷先生翻译的习惯），使正常水平的程序员阅读时毫无障碍。
Martin Fowler首先给出了重构的定义：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。本质上说，重构就是“在代码写好之后改进它的设计”。重构是近几年来才在软件工程领域推出的一个方法论，其最初起源于极限编程（Extreme Programming）过程方法中，但很快就因其完善系统的理论原则和其对软件开发所带来的极大的利处而被其它的软件开发过程所采用，并得到了软件开发人员的认可，在软件工业界也得到了良好的应用。本书是为专业程序员写的重构指南，介绍了重构的一般性原则，以及一些重要的重构方法和准则。有的人可能会问，按照软件工程的思想，应该是先设计，后编码。为什么在编码之后，还要改变其设计？答案很简单：先前的设计存在问题，或是可读性较差，或是效率较差。通常是两者皆有。要注意的是，我们这里讲的，是详细设计，整体的框架设计，不在“重构”的讨论范围之内。重构的每个步骤都很简单，给人“小打小闹”的感觉，但聚沙成塔，这些小的改动，累加起来，可以从根本上改善设计和代码的质量。
虽然这本书是用Java语言描述的，但我想，使用任何语言的程序员，都能读懂这本书和其中的代码，如果感觉实在有困难，读一本最简单的JAVA的入门书即可。Eclipse SDK包括了一个全功能的Java IDE，并且有强大的机制支持代码的重构；但重构绝对不是限于JAVA的。在本书的13章，是伊利诺斯大学（University of Illinois）的博士，William Opdyke写的，其中引用了一篇C++程序重构的论文。另外，据说微软新出的Visual Studio Whidbey也会附带有重构的工具。
程序员，尤其是资历比较浅的程序员，都会有惰性。也不太明白设计的重要性，通常以完成功能为目的，日积月累，软件危机就会产生。正常情况下，在水平提高后，程序员会对自己以前的代码非常看不顺眼，盼望能重新写好。可是，这是一项非常具有风险的活动。Martin Fowler的重构技术，它建立在完备的理论基础之上，并且有完善的方法学指导（包括小步迭代、频繁构建、测试优先等“敏捷联盟”倡导的实践），这使得它不再完全依赖于程序员的天赋。他在书中给出了具体的重构准则和严密的重构手法，使你能够在较低的风险下，重新设计，重写质量比较低劣的代码。
与重构紧密相连的另一个领域就是设计模式。虽然我们知道重构是为了使代码更优美，但怎样才算达到了重构的目标呢？设计模式为我们指明了方向。虽然设计模式是业界所认可的良好的软件设计结构，但不可能从软件开发的开始阶段就把软件按设计模式全面地进行设计，那样只会带来是过分设计，最终浪费了大量的时间却无法获得良好的效果。而重构恰恰可以看作是软件设计的一个修正品，它可以在软件开发的过程中不断的修改现有的程序结构（即设计），而使软件的设计朝着设计模式的方向开去。这也正是重构的目标之所在。Joshua Kerievsky在《Refactoring to Patterns》一书中这样描述重构和模式的关系：Patterns are a cornerstone of object-oriented design, while test-first programming and merciless refactoring are cornerstones of evolutionary design（模式是面向对象设计的基石，而测试优先编程和无情的重构则是设计演进的基石）。
有一点要注意的是：“不改变代码外在行为的前提下”，通俗的说，就是不能改变这段代码实现的功能。这是一个非常重要，又常会有人违反的原则。如果要增加或减少功能，请在重构完成之后！因为重构的目标之一，就是保持代码的功能完全不变。这是本书在最后一章，重构技术的顶尖大师，Kent Beck一再强调的。
讲到这里，可能大家慢慢能理解，重构，最关注的，就是提高软件的质量。提高软件的质量，同时也就提高了开发速度。有些人可能会不理解：要是边写代码，边重构，当然比直接写出完成功能的代码慢呀。可是请你想一想，软件开发中最占用时间的是什么？测试，对，当然是测试。在debug的时候，是对着一堆很差劲，很难懂的代码舒服，还是对着已经重构过，可读性明显提升的代码好？可能在debug的时候，你还是难以忍受那些拙劣的代码，还是会去重构的。所以，在一开始写的时候，带着“重构”的思想去写，或是在写了一小段时间后，回头看一下自己的代码，“勿以善小而不为”，那不会浪费你的时间，从整体上来说，一定会大大节省整个项目的开发时间。
记得读过一篇“葵花宝典:软件开发高手是这样炼成的!”，上面对重构有这样一段经典的话：“高手写软件总是不停地在重构(refactoring)。高手喜欢迭代式开发。高手说，增量就是打补丁，迭代就是推倒重来。对于软件这种东西，写一遍它可能ok（做到这一点也不容易），写十遍就是一个伟大的产品，再多写一遍它就更伟大些。”这就是高质量的软件产生的过程，其实一点都不难，只是看你是否愿意去做。我从一开始就说了，我们程序员的目标，不是拼凑一个能实现功能的垃圾软件，是创造一件伟大的艺术品，重构，是其间的必要步骤。
这本书是值得精读的，作为一个有经验的程序员，可能有部分是你已经知道并在开发过程中会注意的，别的部分，也会觉得很有道理而很容易的就记住了。所以，也许你读完一遍之后将不会再读第二遍，但却会时时刻刻想起它，因为它已经潜移默化了你的习惯。这让我想到了武侠书上说的“无招胜有招”，掌握了“有招”后，更深入的，就是“无招”，用来指导你写代码时的一切思想。正如作者所说，这些重构原则，不可能是全部，但如果你能由这些原则，悟到了如何写高质量代码的“道”，你就成为了一个真正的优秀的程序员了！
当我第一次知道“重构”这个词时，直觉告诉我，这是一项非常重要的技术。因为程序员写代码，虽然越来越趋于工程化，但就程序本身，还是有艺术之美的存在的。曹雪芹先生写《红楼梦》，“批阅十载，增删五次”，留下了恢弘巨著；要写出一个比较优美经典的程序，同样需要精雕细琢，提高其质量，这就是重构。
我手头的这本《重构》，是Martin Fowler主笔的，另外有四位重构技术的专家级人物Kent Beck, John Brant, William Opdyke, Don Roberts也参与了最后几章的编写。这是一本与《设计模式》齐名的经典之作。Martin Fowler，除了是对象技术方面的专家外，还是UML和模式方面的专家。他撰写的Analysis Patterns、UML Distilled、Patterns of EntERPrise Application Architecture和Planning Extreme Programming几本书也广受赞誉。中国电力出版社出版的这本书，是由著名的侯捷先生和熊节先生翻译的。侯捷和熊节先生的翻译非常的到位，并保留了一些大家都能理解的、翻译了反而不通顺的英语单词（这好像是侯捷先生翻译的习惯），使正常水平的程序员阅读时毫无障碍。
Martin Fowler首先给出了重构的定义：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。本质上说，重构就是“在代码写好之后改进它的设计”。重构是近几年来才在软件工程领域推出的一个方法论，其最初起源于极限编程（Extreme Programming）过程方法中，但很快就因其完善系统的理论原则和其对软件开发所带来的极大的利处而被其它的软件开发过程所采用，并得到了软件开发人员的认可，在软件工业界也得到了良好的应用。本书是为专业程序员写的重构指南，介绍了重构的一般性原则，以及一些重要的重构方法和准则。有的人可能会问，按照软件工程的思想，应该是先设计，后编码。为什么在编码之后，还要改变其设计？答案很简单：先前的设计存在问题，或是可读性较差，或是效率较差。通常是两者皆有。要注意的是，我们这里讲的，是详细设计，整体的框架设计，不在“重构”的讨论范围之内。重构的每个步骤都很简单，给人“小打小闹”的感觉，但聚沙成塔，这些小的改动，累加起来，可以从根本上改善设计和代码的质量。
虽然这本书是用Java语言描述的，但我想，使用任何语言的程序员，都能读懂这本书和其中的代码，如果感觉实在有困难，读一本最简单的JAVA的入门书即可。Eclipse SDK包括了一个全功能的Java IDE，并且有强大的机制支持代码的重构；但重构绝对不是限于JAVA的。在本书的13章，是伊利诺斯大学（University of Illinois）的博士，William Opdyke写的，其中引用了一篇C++程序重构的论文。另外，据说微软新出的Visual Studio Whidbey也会附带有重构的工具。
程序员，尤其是资历比较浅的程序员，都会有惰性。也不太明白设计的重要性，通常以完成功能为目的，日积月累，软件危机就会产生。正常情况下，在水平提高后，程序员会对自己以前的代码非常看不顺眼，盼望能重新写好。可是，这是一项非常具有风险的活动。Martin Fowler的重构技术，它建立在完备的理论基础之上，并且有完善的方法学指导（包括小步迭代、频繁构建、测试优先等“敏捷联盟”倡导的实践），这使得它不再完全依赖于程序员的天赋。他在书中给出了具体的重构准则和严密的重构手法，使你能够在较低的风险下，重新设计，重写质量比较低劣的代码。
与重构紧密相连的另一个领域就是设计模式。虽然我们知道重构是为了使代码更优美，但怎样才算达到了重构的目标呢？设计模式为我们指明了方向。虽然设计模式是业界所认可的良好的软件设计结构，但不可能从软件开发的开始阶段就把软件按设计模式全面地进行设计，那样只会带来是过分设计，最终浪费了大量的时间却无法获得良好的效果。而重构恰恰可以看作是软件设计的一个修正品，它可以在软件开发的过程中不断的修改现有的程序结构（即设计），而使软件的设计朝着设计模式的方向开去。这也正是重构的目标之所在。Joshua Kerievsky在《Refactoring to Patterns》一书中这样描述重构和模式的关系：Patterns are a cornerstone of object-oriented design, while test-first programming and merciless refactoring are cornerstones of evolutionary design（模式是面向对象设计的基石，而测试优先编程和无情的重构则是设计演进的基石）。
有一点要注意的是：“不改变代码外在行为的前提下”，通俗的说，就是不能改变这段代码实现的功能。这是一个非常重要，又常会有人违反的原则。如果要增加或减少功能，请在重构完成之后！因为重构的目标之一，就是保持代码的功能完全不变。这是本书在最后一章，重构技术的顶尖大师，Kent Beck一再强调的。
讲到这里，可能大家慢慢能理解，重构，最关注的，就是提高软件的质量。提高软件的质量，同时也就提高了开发速度。有些人可能会不理解：要是边写代码，边重构，当然比直接写出完成功能的代码慢呀。可是请你想一想，软件开发中最占用时间的是什么？测试，对，当然是测试。在debug的时候，是对着一堆很差劲，很难懂的代码舒服，还是对着已经重构过，可读性明显提升的代码好？可能在debug的时候，你还是难以忍受那些拙劣的代码，还是会去重构的。所以，在一开始写的时候，带着“重构”的思想去写，或是在写了一小段时间后，回头看一下自己的代码，“勿以善小而不为”，那不会浪费你的时间，从整体上来说，一定会大大节省整个项目的开发时间。
记得读过一篇“葵花宝典:软件开发高手是这样炼成的!”，上面对重构有这样一段经典的话：“高手写软件总是不停地在重构(refactoring)。高手喜欢迭代式开发。高手说，增量就是打补丁，迭代就是推倒重来。对于软件这种东西，写一遍它可能ok（做到这一点也不容易），写十遍就是一个伟大的产品，再多写一遍它就更伟大些。”这就是高质量的软件产生的过程，其实一点都不难，只是看你是否愿意去做。我从一开始就说了，我们程序员的目标，不是拼凑一个能实现功能的垃圾软件，是创造一件伟大的艺术品，重构，是其间的必要步骤。
这本书是值得精读的，作为一个有经验的程序员，可能有部分是你已经知道并在开发过程中会注意的，别的部分，也会觉得很有道理而很容易的就记住了。所以，也许你读完一遍之后将不会再读第二遍，但却会时时刻刻想起它，因为它已经潜移默化了你的习惯。这让我想到了武侠书上说的“无招胜有招”，掌握了“有招”后，更深入的，就是“无招”，用来指导你写代码时的一切思想。正如作者所说，这些重构原则，不可能是全部，但如果你能由这些原则，悟到了如何写高质量代码的“道”，你就成为了一个真正的优秀的程序员了！
红马天下 版权所有
博客：http://homer.cnblogs.com/
欢迎转载，但转载必须注明作者和出处。
