任何一种技术都不是万能的。正象设计模式，合理的运用可以极大地提高设计的效率和美感，再不适当的场合运用就会产生所谓的反模式。我们的refactoring亦然。
但是，作为一种强有力的设计演变工具，refactoring值得我们付出努力。不能因为对新技术的恐惧而放弃这样的工具，我在这里对可能出现抗拒情绪的一些问题进行了解释。
不应 Refactoring 的场合
程序原型
当你原型化一个系统时，你通常不在乎程序的灵活性和效率。原型的目的仅仅是为了证明一个概念、实现一种探索，加快加深与客户的交流。一旦原型完成，这样的代码就应该丢掉，重新开始正确的编写。但是，一旦原型能够起到演示的作用，继续保留它并按照这样的方式一直实现下去的诱惑将很难抵挡。你会说："程序运行的很好，就用这一个吧！"。从原型开始的目的来看，这样的策略最后是不会成功的。所以Foote甚至说：
要最小化这种将原型直接变为产品的风险，一个办法就是选用一种特定的语言或工具来构建你的原型，而你绝不会使用这种语言或工具完成你的最终产品。
由于原型从根本来说，不会有意考虑以后的变化和程序的结构，对原型做Refactoring是不可能也是毫无必要的。
程序不能工作
如果一个程序本身还不能工作，那么对他进行Refactoring就没有任何意义。Refactoring保留程序的可观察行为，那么Refactoring的结果还是不能正常工作的。
这里并不排除使用Refactoring可以排除bug，但那是在程序的绝大部分主要功能已经实现的情况下。
接近底线
如果你已经接近了最后提交日期，这个时候Refactoring可能产生的效率的提高将发生在底线之后。到那时候，一切都没有意义了。
但是这个问题可以有另外一种考虑的思路，为什么会出现这种情况？是因为估算严重失误还是因为效率太低？如果效率太低，你怎样来提高效率？Refactoring是一种提高生产力极好的方法，因为它使设计更好，从而使得变化更快。所以，如果你发觉时间可能不够，往往就是需要Refactoring的一个信号
实施 Refactoring 可能碰到的阻碍以及解决方案
Refactoring带来的长期利益是每个人都能够看到的，但是并不是每个人都愿意使用它，Opdyke说：
因此，这类技术的支持者可能会惊异于（失望于）这个世界没有人来敲他们的门。
接着，他指出即使已经意识到长期的利益，但人们还是不情愿使用这种方法的四个关键理由：
"我不理解如何应用你的方法 。"
"你的方法只能得到长远利益，为什么要在现在竭尽努力？从长远的角度来看，我可能不再是这个项目或这个组织的一员了"
你的方法是一种开销活动，我是受雇来编写新特性的"
"如果我们应用了你的方法，我们已有的实现可能以不刻预期的方式变化或中断。可性度和向后兼容性对我们很重要".
这些问题其实并不单单存在于Refactoring领域，在鼓励人们设计、编写更重用的系统时，我们也必须解决这些问题：
技术人员可能不理解重用什么以及如何重用；
如果不能看到短期效益，技术人员不会采用提倡重用的方法。
我们必须明确支持重用的方法可能引发的额外学习曲线和其他成本。
采用支持重用的方法不应该打断一个项目；新的实现应当和存在的系统向后兼容。
学习
要想知道如何refactoring，你必须学习。
Refactoring已经被有经验的OO程序员成功地使用了10多年。这些程序员也把他们Refacorting的经验反馈给了OO社团。
本文旨在为你提供一个导引，在学习了这篇文章后，你可以沿着以下几个方向进行深入：
要立刻开始动手进行Refactoring，你的最佳选择就是Martin Fowler的《Refactoring： Improving the Design of Exsiting Code》，该书有一个Refactoring的分类目录。详细描述了70多种Refactoring方法。Martin Fowler的主页（http://www.martinfowler.com/）上还有最近扩展的一些Refactoring方法。
你需要阅读各种好的程序代码和设计结构，特别是设计模式，因为设计模式可以称得上Refactoring的终极目标之一。
你可以到网上搜索各种Refactoring工具，我将在后面介绍，学习使用Refactoring工具进行更安全的Refactoring。
如果你想学习Refactoring方面的理论，请参见我文后附上的各种参考文献，特别是Ralph Johnson教授的文章和他弟子们的博士论文。
另外，在我的主页http://www.erptao.org/上，你可以：
对本文提出评论和建议，以帮助我改进；
在论坛中有refactoring方面的讨论，你可以在那里看到refactoring的一些实践，如果你有问题，可以在那里提出，我将尽量回答。
Refactoring获得短期效益
如果没有短期效益，很难让技术人员直接看到Refactoring的效果。由于Refactoring开始于大学的研究机构和技术前沿的小公司，所以如何在工业主流软件中应用Refactoring成为OO社团实践的一个重要内容。
伊利诺斯大学研究小组的CHOISE操作系统框架是这些研究的一部分。其中，CHOICE实现了对System V，MS-DOS，BSD UNIX等差别极大的不同文件系统的支持。在开发过程中应用Refactoring后，研究者指出refactoring确实能够获得不少短期和长期的利益。
对于近期而言，因为排除了重复代码，在通用代码测试中发现的错误只需要在一个地方进行修改。代码总量变小。与一个特定文件系统格式相关的代码与适合于两个或几个文件系统通用的代码隔离。
对于中期而言，来自于refactoring的抽象通常为以后其他的文件系统提供了方向。事实上，对两个现有文件系统的抽象不一定完全适合于第三个文件系统，但是已经存在的通用代码是一个有价值的起点。后续refactoring应用的结果将显示什么是文件系统真正的抽象。框架开发小组发现，随着实践的推移，加入一个文件系统所需要的努力越来越少。即使后来的文件系统更复杂，开发者更加缺乏经验。
削减Refactoring的额外开销
对于Refactoring所造成的额外开销，你可以这样来看待：
工具和技术的发展使得refactoring更加自动化，能够减少大量的手工劳动和错误介入；
有经验的OO程序员报告，refactoring所造成的额外开销完全能够抵消采用refactoring对程序开发其他阶段的提升。
刚刚开始使用refactoring，你可能会觉得有点别扭。但一旦成为一种习惯，你将不会觉得这是一种额外工作，你会把它当作一个好程序员开发过程自然而然的一部分。
你可以在internet上找到很多这样的报告，后面很多内容也都谈到了这个问题。
安全Refactory
保持可观察的行为被称为Refactoring的安全性。要实现安全的Refactoring，你通常有几种选择[William Opdyke]：
相信你自己的编码能力；
相信专家、文献提供的步骤能够帮助你减少错误。
相信编译器能够捕获你没有发现的错误；
相信你的测试套件能够捕获编译器没有发现的错误；
相信Code Review会捕获你、你的编译器、你的测试套件漏掉的错误
各种各样的书籍、资料、论文、期刊可以增强你的编程能力，能够教给你更多的良好风格。Martin Fowler的《Refactoring》就是这样一本书，他告诉我们Refactoring有非常细小的一步一步组成，每一步看起来都不起眼，但是一系列Refactoring的结果会对系统产生有力的影响。
编译器、好的风格、测试套件、Code Review都是非常有价值的，但是所有这些方法方法都有他们的问题，编译器根本不知道程序的动态行为，好的风格、Code Review完全依靠人来实现，而任何一个人都会犯错误。测试套件也没有办法覆盖所有的行为。
所以，面向软件社团对Refactoring的一个重要研究方向，就是定义Refactoring安全性方面的理论并实现这种理论支持下的工具。它们可以用来检查某一种Refactoring是否能够安全地应用到一个程序，如果安全的话，那么就有工具来完成Refatoring。这样做也避免了手工完成可能引起的bug。
关于作者
石一楹，现任浙江大学灵峰科技开发公司技术总监。多年从事OO系统分析、设计。现主要研究方向为Refactoring和分析模式。
