original="http://ittopic.gotoip1.com/qee/wordpress/wp-content/uploads/2013/10/slide-1-728-800x450.jpg" />
英文原文:Hill Climbing (Wonkish)
重构是一种对软件进行修改的行为,但它并不改变软件的功能特征,而是通过让软件程序更清晰,更简洁和更条理来改进软件的质量。代码重构之于软件,相当于结构修改之于散文。每次人们对如何对代码进行重构的讨论就像是讨论如果对一篇文学作品进行修订一样无休无止。所有人都知道应该根据项目的自身情况来对代码进行重构,而重构是无止境的。莫扎特从来不不对他的作品进行修订,特罗洛普对自己作品修订的恰到好处,大多数作家认为他们俩这样做都是合适的,但他们的合适对于你我来说未必是合适的。
最常见的基本重构方法可以归纳为两个方向。通过归纳方法将一个长的过程分解为小的可以重用的组件,和通过内联(inline)方法来消除那些不够份量的小方法。我们可以提炼方法来让大量的子类共享相同的功能特征,我们可以下放方法来让只有用到这些功能的子类才知道它们的存在。重构就是爬山,通过一步一步的小的提高来逐渐的改进整体的质量,但在重构时,我们如何知道哪种方法是上山的正确道路?
关于代码地形学的这个问题公认的方法有两种。去除有异味的代码和重构成模式。如果能做到这样,当然是很好的。就像是纠正作文里的一个语法错误或不恰当的比喻。如果我们可以找到这些四处隐藏的有异味的代码,将它们重写成整洁的,条理的,结构化的形式,何乐而不为。但这些都是特殊情况。如果没有明显的模式来重构,或没有很直接的方法来去除代码异味,那该怎么办呢?
这才是我们如今编程艺术的中心问题,而很少人讨论这些。通常我们讨论这些问题时都是罗列出更多更长的有异味的代码模式的清单,但这并不是解决问题的方法。代码异味应该是我们公认的不好的东西,而不是那些置之不理也无妨的事情。我们经常会说到老板不给我们重构的机会,甚至代码有明显的异味,老板们认为这是浪费时间。并不是每个人都有懂软件的老板。我很吃惊为什么只有很少的讨论谈到点子上。。也许我这篇文章才说到问题关键处。
我的观点,当重构没有现成的明显的方向时,我们可以遵循下面的原则:
else
语句。