Java代码分析器(六): 大规模自动重构经验谈 - 快车库

最后再啰嗦一篇吧，分享些宏观经验，供需要做类似事情的人参考。

技术示例在前篇! 伸手党绕行!

大规模系统重构，不可避免要触到各个团队/模块的很多代码，很可能破坏功能，到时候你就成众矢之的了，tickets扑面而来，到处灭火。

怎么确保不破坏功能呢？就要做安全重构。(2016/4/16做了补充，以方括号[]标出)

充分了解系统架构，调查各种代码模式和场景(争取发现corner case)，手工重构几个试试。
```
[然后把手工过程给自动化]
```
尽量做等价变换，把代码改成等价形式，一般都是安全的。(注意：涉及反射的代码无法等价变换。)
```
[改变类结构，对非反射代码是等价的，对反射代码是不等价的]
```

绝不能改变代码语义(重构本来就不该改变语义)。

[接口级行为不变，内部行为尽量不变，类结构尽量不变]

为代码模式和场景确立一组明确的前提条件，重构必须满足前提条件才能进行。
```
[分类处理，列出计划再行动]
```
如果完美做到以上三点，新代码基本上是不需要测试的(抽样测试即可)，否则要做针对性的测试。但是大规模难以完美做到这三点。
```
[TraceSonar辅助确立测试范围 https://github.com/sorra/TraceSonar]
```
简单重构只需要语法分析，复杂重构可能需要语义分析。该做的工作要做足，别出篓子。
```
[实践发现Most Valuable Product只够用来demo]
```
难以自动判断的场景，可以作标记(例如在该位置造成编译错误或插入注释)。自动重构结束后，找到标记(例如编译一遍)，然后人工处理。
```
[注释无法直接插入，如果你想知道解决办法，请评论]
```
尽可能自动化。一来节约人力，二来机械重复的人工操作极易出错，而机器是不会犯错的。因此自动重构是革命性的技术。
```
[还可以自动生成改动列表, 相关文档, etc.]
```

补充：如果资源允许，当然要做好测试。

是不是写得太抽象？大家给点反馈。