最近需要重构一个项目的代码。纯代码2.5W行。
质量就不多说了，看到这样的太多了。
就是开始的时候不知道怎么下手。
本来想通过大的架构的改变直接重构，但。。。风险太大。。。
比如，前台使用state模式进行重构，设计的业务有10几个，一来时间不允许，二来改完可能测试不到。
于是，找了一个统计代码圈复杂度、方法行数等质量参数的工具，挨个进行修改。。。按照业务逻辑提出小方法---把功能类似的代码放到单独的类中--这些都是工具做的，所以不存在什么风险。
经过几个类的修改之后，初步显现出一些效果：
1.每个类的行数变少了，职责单一了，比如一个2000行的类，经过各种提方法，抽出重复代码，变为了2个400行左右的类。
2.由于1，多人的协作冲突减少了--比如两个人做两个功能，需要改同一个类，修改后，两人可以改自己需要的类不需要担心代码提交冲突了。
3.修改后的类，很容易就发现可以使用一些设计模式进行重构---简单了、安全了。
看，简单的做一些重构就可以收获这么多，而且时间消耗也不到，可以说性价比很高。
重构不是革命、不需要轰轰烈烈。
只要细心、耐心。
最好是经常重构，以免技术债务越来越多----相应的利息也会更多，这点任何有经验的开发人员应该都有深刻的体会。
所以，没事的时候，多跑跑checkstyle、findbugs，一些质量检查的小工具，可能看起来改了效果不大，但积累起来的效果是不可估量的。
养成好的习惯吧，重构不是什么有技术含量的事，起码对于国内大多数代码来说。
当小重构到一定程度的时候----基本没有重复代码、类和方法职责单一、没有编译器警告。---你会发现大的重构是那么自然，那么的水到渠成。
重构只是个体力活而已。
PS：重构需要自动测试来支持。如果实在没有，手工测试吧。。。更是体力活。。。