关于重构的重要目标之一，便是让代码更容易让人阅读和理解。其实，代码的好与坏在一定程度上是一模一样的，至少对计算机而言，能正常工作的代码都不算太坏。但是，代码也必须能让其他人看懂码农的思想世界，这才是重构存在的意义了。但是，重构的时机把握远比理解重构的意义重要的多。下面简单说明下，重构的时机问题。
一、重复代码结构或语句块，尽量抽取成独立的模块，类或函数均可；
二、过长的函数，尽量将函数缩小，减小中间变量，局部变量、参数等变量；需要特别注释的代码尽量函数模块化，积极分解函数，并尽量为函数取一个顾名思义的好名称也很重要；条件表达式和循环部分也可以提炼成函数；
三、过大的类，函数功能过于复杂，不便于理解和使用；变量多，代码多，逻辑复杂；
四、参数列表过长，参数容易被遗漏；
五、发散式变化的代码，如果需求改变，需要修改多类代码，往往需要将代码的改变集中在一处或类中，主要是一个类受多种变化的影响；
六、代码的一处改变，需要修改多个类中的代码，主要是一种变化引发多个类相应修改；
七、对象技术的要点是：将数据和对数据的操作包装在一起的编程技术，如果一个类中的方法使用其他类中的数据比使用所在类中的数据更多，说明方法需要移动到相应的类中更加合理，这就是依恋情结；
八、数据泥团：数据项也喜欢扎墩儿，如果许多类中出现相同的数据项，可以考虑雷同的数据项提炼成一个类处理；
九、基本类型偏执：编程环境中，一般都有基本类型和符合类型，如果符合类型数据用的地方够多，最好提炼成类使用更方便；
十、switch现身的地方：凡是出现switch的地方，基本会出现较多判断的场合，可以将其提炼成函数；
十一、平行继承体系：当为一个类增加一个子类时，必须为另一个类增加子类时，需要重构了；
十二、冗余类：如果一个类的投入比产值还多，就需要被K掉了；
十三、过多的规划代码：预备的处理方式或变量从来没有用过，删除；抽象类使用不足，可以变成具体类；类的作用只是用来测试，删除；
十四、令人眼花缭乱的字段：只为特定作用的变量；使用情况不多的多个字段，可以将其提炼成一个类；
十五、耦合过度的调用链：如果一个调用A时调用B，B调用C，C调用D，D调用E，最后使用E提供的数据，存在耦合过度；
十六、委托过度：一个封装好的类中如果大部分函数都和外面代码有关联就是委托过度；
十七、狎昵关系：如果类中的私有成员常被其他类惦记，说明需要重构了；
十八、异曲同工：如果两个函数签名不一样，做着同样的事情，需要重构；
十九、类库的不完美：面向对象的最终目标是代码复用，而类库是最直接的展现形式，如果只是需要添加类库的个别功能，可以自行处理，否则需要重构类库；
二十、纯粹的数据类：只包含有基本的数据和对数据的基本访问的类，这些类应尽量隐藏；
二十一、应用拒绝：子类在继承父类的数据成员和函数成员时，不需要所有的成员时，需要改进继承的套路；
二十二、过多的注释：如果代码需要大段的代码注释，往往不如直接用简单的代码实现效果更好；
编程终极法则：事不过三，三则重构。是说第一次做某件事时尽管放心去做；第二次做某件类似的事时，会产生好感，无论如何还可以去做；第三次再重做某件类似的事时，就应该重构。重构的时机，严格来说，重构应该是随时随地的才行，非要说具体的时机：添加功能时重构；修补错误时重构；复审代码时重构；就足够了。