最近一直在做这块的事，我来谈谈自己的体会
1 首先要了解整个系统的结构
如果在不了解系统的大体的结构情况下做重构，这个相信意义是不大的。
2 为什么要重构？
是系统的效率太低？还是代码有大量的重复，模块间的耦合严重，甚至类间的关系依赖性太强？找出病因才好对症下药，重构需要有针对性。
3 合理的重构计划
一个小的APP可能很好重构，但是当有一个有几万源代码的系统中全部做重构是不明智的，可以分阶段，按功能模块逐个做重构，要不然时间跨度太大容易导致身心疲惫。
4 重构中的一些体会
兼容：兼容以前旧的数据，这个对于web 程序来说还好点，对于客户端来说就比较麻烦了，当一个新的版本发出的时候，并不是所有的用户都很乐意升级的，一旦旧的版本的程序crash 很多用户可能就不再使用你的产品了。
扩展：如果这一块做不好，下一个程序员在使用你新设计的模块时候还得继续重构，重构的意义也不大，一方可以展望未来可能有的功能，预留好接口，另一方面是：抽象。

UI和业务逻辑的分离：在系统版本稳定后发现很多时候我们是在修改UI ，业务逻辑修改的一般不是很多。MVC 这个设计模式还是还有道理，view 和Control 尽量分开。

大量重复的代码：我们可能发现很多时候一个功能有很多分支，只是有稍微一点差异，可能就要写两个函数来区分下，但是两个函数中可能大部分代码是一样的。我们可以把相同的代码抽取出来成为一个子函数。
还有一个场景是这样的：有时候程序的行为需要变动下，但是处理这个行为的类都是在各个Class 中处理的，这样我们就需要做个找出执行这个行为的函数，并修改，很麻烦，这个时候如果将这个行为抽象出来，由统一的一个Class来管理是不是更好。

使用宏，枚举等：很多时候我们的程序中出现很多的数字，比如0，1 ，199 ，1024？ 其他程序员第一眼看到一般都不知道什么意思，即使通读一遍程序后也很可能和原作者理解的产生偏差，这种情况下使用宏来说在合适不过了。特别是在多出使用这个数字或者 string 的时候。

设计模式：我认为她给出解决我们经常遇到一些问题的方法，但是为了使用设计模式才进行重构的话有点勉强。

本人新手，仅个人拙见，轻拍。