石一楹 (shiyiying@hotmail.com) 任何一种技术都不是万能的。正象设计模式,合理的运用可以极大地提高设计的效率和美感,再不适当的场合运用就会产生所谓的反模式。我们的refactoring亦然。 但是,作为一种强有力的设计演变工具,refactoring值得我们付出努力。不能因为对新技术的恐惧而放弃这样的工具,我在这里对可能出现抗拒情绪的一些问题进行了解释。 程序原型 要最小化这种将原型直接变为产品的风险,一个办法就是选用一种特定的语言或工具来构建你的原型,而你绝不会使用这种语言或工具完成你的最终产品。 由于原型从根本来说,不会有意考虑以后的变化和程序的结构,对原型做Refactoring是不可能也是毫无必要的。 程序不能工作 这里并不排除使用Refactoring可以排除bug,但那是在程序的绝大部分主要功能已经实现的情况下。 接近底线 但是这个问题可以有另外一种考虑的思路,为什么会出现这种情况?是因为估算严重失误还是因为效率太低?如果效率太低,你怎样来提高效率?Refactoring是一种提高生产力极好的方法,因为它使设计更好,从而使得变化更快。所以,如果你发觉时间可能不够,往往就是需要Refactoring的一个信号 实施 Refactoring 可能碰到的阻碍以及解决方案 因此,这类技术的支持者可能会惊异于(失望于)这个世界没有人来敲他们的门。 接着,他指出即使已经意识到长期的利益,但人们还是不情愿使用这种方法的四个关键理由:
这些问题其实并不单单存在于Refactoring领域,在鼓励人们设计、编写更重用的系统时,我们也必须解决这些问题:
学习 Refactoring已经被有经验的OO程序员成功地使用了10多年。这些程序员也把他们Refacorting的经验反馈给了OO社团。 本文旨在为你提供一个导引,在学习了这篇文章后,你可以沿着以下几个方向进行深入:
另外,在我的主页http://www.erptao.org/上,你可以:
Refactoring获得短期效益 伊利诺斯大学研究小组的CHOISE操作系统框架是这些研究的一部分。其中,CHOICE实现了对System V,MS-DOS,BSD UNIX等差别极大的不同文件系统的支持。在开发过程中应用Refactoring后,研究者指出refactoring确实能够获得不少短期和长期的利益。 对于近期而言,因为排除了重复代码,在通用代码测试中发现的错误只需要在一个地方进行修改。代码总量变小。与一个特定文件系统格式相关的代码与适合于两个或几个文件系统通用的代码隔离。 对于中期而言,来自于refactoring的抽象通常为以后其他的文件系统提供了方向。事实上,对两个现有文件系统的抽象不一定完全适合于第三个文件系统,但是已经存在的通用代码是一个有价值的起点。后续refactoring应用的结果将显示什么是文件系统真正的抽象。框架开发小组发现,随着实践的推移,加入一个文件系统所需要的努力越来越少。即使后来的文件系统更复杂,开发者更加缺乏经验。 削减Refactoring的额外开销
你可以在internet上找到很多这样的报告,后面很多内容也都谈到了这个问题。 安全Refactory
各种各样的书籍、资料、论文、期刊可以增强你的编程能力,能够教给你更多的良好风格。Martin Fowler的《Refactoring》就是这样一本书,他告诉我们Refactoring有非常细小的一步一步组成,每一步看起来都不起眼,但是一系列Refactoring的结果会对系统产生有力的影响。 编译器、好的风格、测试套件、Code Review都是非常有价值的,但是所有这些方法方法都有他们的问题,编译器根本不知道程序的动态行为,好的风格、Code Review完全依靠人来实现,而任何一个人都会犯错误。测试套件也没有办法覆盖所有的行为。 所以,面向软件社团对Refactoring的一个重要研究方向,就是定义Refactoring安全性方面的理论并实现这种理论支持下的工具。它们可以用来检查某一种Refactoring是否能够安全地应用到一个程序,如果安全的话,那么就有工具来完成Refatoring。这样做也避免了手工完成可能引起的bug。
|
Refactoring Patterns (Forth Part)
最新推荐文章于 2022-06-10 09:15:26 发布