重构 -- 改善既有代码的设计

重构(refactoring)这个概念来自Smalltalk圈子，没多久就进入了其他语言阵营之中。由于重构是framework(架)发中不可缺少的一部分，所以当famework开发人员讨论自己的1作时,这个术语就诞生了,当他们精炼台己的class hierarchies(类阶层体系)时，当他们叫喊自己可以拿掉多少多少行代码时，重构的概念浮出水面。framework设计者知道，这东两不可能开始就完全正确，它将随着设计者的经验成长而进化:他们也知道，代码被阅读和被修改的次数远远多于它被编写的次数。保持代码易读、易修改的关键，就是重构--对famework而言如此，对一般软件也如此。

好极了，还有什么问题吗?很显然:重构具有风险。它必须修改达作中的程序，这可能引入一些幽微的错误。如果重构方式不恰当，可能毁掉你数天甚至数星期的成果:如果重构时不做好准备，不遵守规则，风险就更大。你挖自己的代码，很快发现了，些值得修改的地力，于是你挖得更深,挖得愈深,找到的重构机会就越多…于是你的修政也愈多，最后你给自己挖了个大坑，却爬不出了。为了避免白坟墓，重构必须系统化进行。我在《DesignPatterns》中和外三付(协同)作曾经提过:design parterns(设计模式)为refactoring(重构)提供了日标。然而i确定日标」只是问题的一部分而已，以造程序以达目标，是另一个难题。