代码重构的问题与解决方案

虽然经过了系统架构和设计的重构，系统的结构已经得到了很大程度的改善。但是，最
终我们还需要进行一个更低层面但绝对重要的重构工作，这就是系统代码重构。
我们在浏览一个系统代码后，通过经验及直觉就能发现的一些“坏味”，例如：
代码的方法过大。
系统中重复的代码过多。
类的子类中存在大量相同方法。
代码中过多的注释。
参数列表太长。
那么一般我们应该选择怎样的时机去解决这些问题呢？通常，有如下四种时刻最合适进
行代码重构。反之，如果随意选择代码重构的时刻，则会使系统代码更加混乱：
当我们试图将新的功能代码集成进系统代码前。
当调试系统代码发现 Bug 时。
当我们进行常规代码评审时。
系统架构和设计重构结束后。
需要强调一点，在我们真正动手前，明确代码重构通常所遵循的原则也有着极为重要
的意义：
必须创建相应的大量测试用例和测试脚本。
代码重构要遵循小步调的工作规模（小计划、小构想、小改动、小测试）。
先拿问题最严重或最危险的部分开刀。
一定要利用测试进行验证。如果测试失败，就需要重复进行上述动作。
执行代码重构，不是简单地依靠自己的直觉进行代码修改。往往还需要参考业界在代码
重构实践经验的基础上，提炼出来的那些类似于设计模式的“代码重构模式”来进行工作。
下面我们以几个最基本的代码重构模式作为示例，来看看前人总结的有用的重构经验。
1，方法抽取
问题：
浏览一个 Class 的代码，经常会发现该 Class 不同的方法代码中，会重复出现很多完全
一致的代码。这些重复的代码与各个方法内的功能代码混杂在一起，非常难以理解这个 Class
的功能结构。
解决方案：
代码结构需要简捷明了，否则混杂在一起的代码难以理解，可以将这些重复出现的代码
抽取出来，汇总在该 Class 适当的新方法中。原先调用的位置，只留下对新方法的调用代码。
2，使用有语义的变量名称
问题：
浏览系统代码，经常遇到的一个普遍问题，就是代码中大量使用了一些没有明显语义的
变量，例如：代码中声明了一个变量 a，但是当你看到这个变量时，并不能立即明白其用途。
解决方案：
代码的可读性在很大程度上决定了系统代码的可维护性。根据统计数据显示，超过 50%
的代码重构时间都花在了理解原有代码上。因此，定义变量时，尽量使用一些与变量用途或
使用逻辑相关的名称。
在实际的代码重构过程中，可以使用一些工具来进行辅助。许多开发环境都集成了重构
的部分功能，这些工具在一定程度上可以帮助我们来避免不必要的编码错误，帮助检查代码
的一致性，提高了重构的效率。但是，正如 Booch 曾经说过的一句名言：“依赖工具的人，
将最终被工具所玩弄”。由于代码重构具有明显的经验要求，所以绝大部分还是需要依靠重
构人员的智慧和经验。
无论是架构和设计重构，还是系统代码重构，都是相互依赖和相互联系的。如果我们进
行架构和设计重构时，没有系统代码作为支撑，就不能完全掌握系统内部结构的关系。同时，
一次增量式的小规模设计重构，非常有可能成为触发后续系统代码相应部分的重构动作。例
如：我们对系统内一些元素的名称进行了修改，那么我们自然对相应的代码（包名称、类名
称、方法名称等）进行修改。所以，在进行架构和设计重构时，如果能够详细记录设计变化
所涉及的代码，将对后续的代码重构非常重要。
下面我们会更详细的讨论这个问题。