参考《重构_改善既有代码的设计》
1 有注释的代码，往往可以提取出一个函数出来；查询函数和修改函数也单独提取出来，同时使用时，使用一个新方法，加上sync锁就行
2 变化频繁的地方可以使用多态来进行重构，争取每次的变化只需要新增一个对应类和修改配置
3 ifelse过多/嵌套过深，可以考虑使用策略模式
4 方法应该决定好归属的类，而不是都堆到一起，否则类会太大，实例变量也是一个道理，尽量将属于同一类的抽取出来成为单独的类，善用继承
5 ifelse、while、for往往可以提取成一个单独的函数
6 参数列表过长，可以考虑将参数列表抽到一个对象里，如果这个参数列表用的地方很多的话；这样也可以方便扩展，修改时不需要每个调用方都修改参数列表，直接统一修改对象即可
7 一个类如果每次修改都需要修改多个无相关的方法，可以考虑拆分类，达到每次只需要修改一个方法的目的，并且尽量将“需求变化时，需要修改的代码”尽量放到同个类中，也就是说，将总是一起变化的东西放在一起，如果不能放一起，就抽一个类作为中间层
8 多个类如果有多个相同的字段，可以考虑是否抽取出来做一个单独的类有业务意义
9 如果两个继承体系有点类似，可以考虑用组合来消除其中一个体系
10 临时变量会影响重构，能不要就不要吧
11 去除非必要的间接性
12 可以考虑把临时变量提取为方法进行调用，可以使用final来判断是否确实是只被赋值一次
13 可以使用常量来取代一些固定表达式，也就是所谓的解释性变量
14 临时变量尽量只做一次性用途，命名准确，而不是一个temp走天下
15 对参数进行操作时，可以考虑用一个新的变量来操作，可读性提升，也能避免一些引用修改的问题
16 如果一个大型函数有众多的局部变量导致难以抽取成多个小方法，可以考虑将这个函数做到一个单独的类里，将局部变量变成字段
17 一个小类是否要合进另外一个类/一个大类是否要拆某些联系紧密的字段出来做为一个单独的类，就看这些字段是否有被复用的可能性，或者说是否能成为一个领域里的对象
18 善用包装类，即委托模式、门面模式等，避免孤苦伶仃的方法、字段
19 慎重思考对象与对象之间的关系，究竟是几对几？需要考虑上未来的预期发展
20 可以考虑将相同类型的类型码抽取出来做一个类，这样可以方便类型校验
21 可以考虑把if里的判断条件提取出来做成函数，如果很长的话
22 抛出自定义异常来取代错误，而不是返回码；不过别滥用异常，比如参数检查的问题，就用if检查了，别直接扔异常
23 不同类有类似的逻辑顺序，具体操作不同的方法，可以使用模板模式
