替换日志框架过程中对重构的思考

新的SPI日志框架开发完成后，便着手替换之前的日志逻辑，即用新的日志框架来重构之前的代码。在这个过程中，如果遵循正确的方法会使这个周期缩短，准确率也会提高，以下是在此次重构过程中总结的几条经验。

1. 动手之前先了解日志的业务逻辑，并统计涉及修改的类

1）程序中的代码逻辑几乎都暗合具体的业务逻辑，重构已有的逻辑之前，要了解已有的逻辑。

2）统计需要修改的类，预估工作量。

2. 根据业务逻辑，由主及次的对涉及到的类进行修改

由主及次的去重构，基于以下的事实：

1）主要的逻辑往往包含了复杂的逻辑，需要集中精力去修改；

2）次要的逻辑往往逻辑比较简单，只需要机械的替换即可，不需花费太多的精力；

3）随着重构时间的拉长，人的厌倦感会增加，精力会损耗; 所以，由主及次的修改往往会使重构的效率大幅增加。

3. 测试阶段暂时注释旧代码（不要删除），正式发布时剔除注释的旧代码

测试阶段以注释的方式保留旧代码有以下好处：

1）这样方便比对，比用版本控制去溯源要方便，所见所得。

2）替换时，可以很方便的查找之前已经执行的替换，直接拷贝稍作修改即可。

4. 在新的feature分支或hotfix分支上进行重构

不影响已有环境。

5. 一次重构尽量控制保证变化的可测性，若过多变化需要拆解为多次重构

1. 重构一定要结合测试，而如果要确保测试的可行性和准确性，就要控制每次重构的变化量。
2. 重构是一个迭代的过程：重构A --> 测试A --> 重构B --> 测试B ...
3. 如果变化过多，需要拆分。例如本次日志框架的重构的早期目标为a.替换原有的日志框架;b.修改已有的字段名称；最终我决定先完成a，因为a+b无法完整测试。

6. 初期建议本地测试，通过IDEA remote连接调试比较方便，减少（定位错误->修改->发布）的时间周期

END. 写在后面

针对本次日志框架的重构，我总共重构了两次，以下是耗时列表（不包含测试时间）：