重构

没有任何度量比得上见识广博者的直觉。 在我看来，一篇好文章应该是简单、形象、易懂的。 再次意识到，设计模式使用方面的确是很多的！ 阅读介绍经验的书籍时，你如果有足够的经验，那么会引起共鸣，也会有更好的理解。 利用“臭味”条款来选择对应的方法。观察重要的特征。 # 重复的代码。尽可能减少。 类中的重复方法合并； 子类互相重复的方法提炼为父类的方法（我认为还得看方法的重要程度，要是一千个子类中两个子类重复了，那么不应该提炼到父类中）； 类似的方法提炼出相同部分的子过程； 不同的算法做同样的事情，利用简单的、清晰的替换掉另外一个。 两个无关类有相同过程，则应该看情况决定是否应该提炼出第三个类。 # 过长函数。拥有短函数的对象会活的比较长。 程序愈长愈难理解。 当我们感觉应该给一个函数加注释的时候，我们就应该把这部分提炼成独立函数，并以用途命名，（简单易懂，我喜欢），哪怕替换后的函数调用比函数体还长，只要能够说清楚干了什么，也值得这样做。 如果参数太多，那么应该利用查询代替参数，亦或是直接重写函数。 注释、条件、循环都是提炼的信号。 # 过大的类。 变量过多。。方法过多。。 提炼方法，消除过多代码。 # 过长参数列。 用方法替换参数，请求数据。 # 发散式变化。一个类对应多种变化，则应该分裂类。 针对某一外界变化的相应修改，都应该只发生在一个类中！？？？ # 霰弹式修改。一个变化对应多个类，则应该合并。 把所有需要修改的代码移动到同一个类中。 # 依恋情节。 函数应该放在它依赖最多数据的那个对象。 # 数据泥团 用新类代替重复出现的数据？ # # 面向对象，少用switch。因为switch重复，多态可以带来更好的解决…… # 平行继承体系。消除这种依赖，利用引用？ #…… 消除冗余的类；删掉不用的功能；不用为将来打算太多？ 把临时变量提炼到method object中；过度耦合；利用继承消除过多的中间代理；消除过度亲密的类，用代理代替继承；合并异曲同工的类？；弥补不完美的类库；封装数据类。 # 如果要注释代码，那么提炼方法；如果要注释方法，那么重新命名方法；如果需要注释说明规格，那么用断言。 想写注释时，先重构。 当不知道做什么的时候，才是注释的良机，你可以记录下你的想法，你将来想干什么？

Joshua Kerievsky在那篇著名的《模式与XP》〔收录于《极限编程研究》一书）中明白地指出：在设计前期使用模式常常导致过度工程（over-engineering)。这是一个残酷的现实，单凭对完美的追求无法写出实用的代码，而「实用」是软件压倒一切的要素。 TIP：如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地那么做，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。 TIP：重构之前，首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验（self-checking）能力。 TIP：重构技术系以微小的步伐修改程序。如果你犯下错误，很容易便可发现它。 Smalltalk 也的确拥有这样的工具——Refactoring Browser。运用这个工具，重构过程非常轻松，我只需标示出需要重构的代码，在选单中点选Extract Method，输入新的函数名称，一切就自动搞定。而且工具决不会像我那样犯下愚蠢可笑的错误。