重构是一种修改软件的行为，但它并不改变软件的功能特性，而是通过使软件程序更清晰、更简洁、更有条理来提高软件的质量。代码重构之于软件就像结构修改之于散文。每次人们讨论如何重构代码，就像讨论如何修改文学作品一样。大家都知道代码要根据项目自身情况进行重构，重构是无止境的。莫扎特从不修改他的作品，而特罗洛普所做的恰好足以修改他自己的作品。大多数作家认为他们两个人这样做是合适的，但他们的合适性可能不适合你或我。最常见的基本重构方法可以概括为两个方向。通过归纳法将一个长流程分解成小的可重用组件，通过内联法淘汰那些不够用的小方法。我们可以细化方法，让大量的子类共享相同的功能特性，我们可以分散方法，让只有使用这些功能的子类知道它们的存在。重构就是爬山，通过一步一步的小改进逐步提升整体素质，但是在重构的时候，我们怎么知道哪种方式才是正确的上山方式呢？对于这个代码拓扑问题，有两种公认的方法。删除臭代码并重构模式。如果能做到这一点当然太好了。就像纠正作文中的语法错误或不恰当的比喻一样。如果我们能找到这些隐藏的臭代码并将它们重写成干净、有组织和结构化的形式，那为什么不呢。但这些都是特例。如果没有明显的重构模式，或者没有直接的方法来消除代码异味怎么办？这是我们当今编程艺术的核心问题，而且很少被讨论。通常我们会用越来越多的臭代码模式列表来讨论这些问题，但这并不是解决问题的方法。代码味道应该是我们认为不好的东西，而不是可以忽略的东西。我们经常说老板不给我们重构的机会，连代码都有明显的味道。老板们认为这是浪费时间。不是每个人都有懂软件的老板。我很惊讶很少有人讨论到重点。.或许我在这篇文章中刚刚触及了问题的症结所在。在我看来，当重构没有现成的明显方向时，我们可以遵循以下原则：当有任何重用属性、方法或类的意图时，对其进行总结和提炼。不要低估小方法对代码清洁的作用。使用小方法可以为您节省大量的笔墨。所有可以缩短代码长度的改进都应该进行改进，包括注释。使用switch()而不是多态-即使它会使代码更长。通过封装控制可见性。消除依赖性。简化构造函数——即使这样做会使代码复杂化。封装或避免条件表达式。使用guard语句并避免else语句。使用常量而不是幻数。当有疑问时，支持组合而不是继承。当有疑问时，将计算操作移动到这些数据的所有者对象中，或者将数据移动到执行计算操作的对象中（即迪米特法则）。使用小对象，松耦合，避免大对象，高聚合。如有疑问，更喜欢递归而不是循环。使用代理对象、模拟对象和帮助对象来隔离网络、数据库、文件和用户界面。当您不确定时，尝试在模型中添加代码，并且仅在必要时才向控制器添加代码。应该在视图中添加便利函数和速记方法，但不要局限于此。更喜欢使用apply、each、mapcar而不是loop。尝试使用新技术。原文链接：http://www.markbernstein.org/Oct13/HillClimbingWonkish.html翻译链接：http://www.aqee.net/hill-climbing-wonkish/
