＋设为首页 ＋添加到收藏夹
不应 refactoring 的场合
【相关文章:设计模式c#语言描述——合成（Compo】程序原型 【扩展阅读:在DELPHI7中不使用任何第三方控件,】
要最小化这种将原型直接变为产品的风险，一个办法就是选用一种特定的语言或工具来构建你的原型，而你绝不会使用这种语言或工具完成你的最终产品。 【扩展信息:层遇到select框时】
当你原型化一个系统时，你通常不在乎程序的灵活性与效率。原型的目的仅仅是为了证明一个概念、实现一种探索，加快加深与客户的交流。一旦原型完成，这样的代码就应该丢掉，重新开始正确的编写。但是，一旦原型能够起到演示的作用，继续保留它并按照这样的方式一直实现下去的诱惑将很难抵挡。你会说："程序运行的很好，就用这一个吧！"。从原型开始的目的来看，这样的策略最后是不会成功的。所以foote甚至说：由于原型从根本来说，不会有意考虑以后的变化与程序的结构，对原型做refactoring是不可能也是毫无必要的。
程序不能工作
如果一个程序本身还不能工作，那么对他进行refactoring就没有任何意义。refactoring保留程序的可观察行为，那么refactoring的结果还是不能正常工作的。这里并不排除使用refactoring可以排除bug，但那是在程序的绝大部分主要功能已经实现的情况下。
接近底线
如果你已经接近了最后提交日期，这个时候refactoring可能产生的效率的提高将发生在底线之后。到那时候，一切都没有意义了。但是这个问题可以有另外一种考虑的思路，为什么会出现这种情况？是因为估算严重失误还是因为效率太低？如果效率太低，你怎样来提高效率？refactoring是一种提高生产力极好的方法，因为它使设计更好，从而使得变化更快。所以，如果你发觉时间可能不够，往往就是需要refactoring的一个信号
实施 refactoring 可能碰到的阻碍以及解决方案
refactoring带来的长期利益是每个人都能够看到的，但是并不是每个人都愿意使用它，opdyke说：因此，这类技术的支持者可能会惊异于（失望于）这个世界没有人来敲他们的门。
接着，他指出即使已经意识到长期的利益，但人们还是不情愿使用这种方法的四个关键理由：
"我不理解如何应用你的方法 。" "你的方法只能得到长远利益，为什么要在现在竭尽努力？从长远的角度来看，我可能不再是这个项目或这个组织的一员了" 你的方法是一种开销活动，我是受雇来编写新特性的" "如果我们应用了你的方法，我们已有的实现可能以不刻预期的方式变化或中断。可性度与向后兼容性对我们很重要". ... 下一页