重构

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

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

「异常」只应该被用于异常的、罕见的行为，也就是那些「产生意料外的错误」的行为，而不应该成为「条件检查」的替代品。

稳定的接口确实很好，但是被冻结在一个不良接口上，也是有问题的。