重构的全盘思考

1. 技术栈是否成熟?
2. 项目本身是否稳定?
3. 项目本身是否稳定?

技术栈是否成熟?

1. 有稳定版, 却 bug 比较少
2. 有明确的官方文档

项目本身是否稳定?

项目本身没有什么 bug , 才会去重构

如果是特殊情况, 在有小 bug 、小需求的情况下也要重构

• 重构项目初期, 重构的时间占比 20%
• 当大部分功能都迁移后, 重构时间就可以占大部分了

梳理差异点

重构顺序

• 比较冷门的业务开始重构 -> 比较热门的业务开始重构
• 关联比较少的功能开始重构 -> 关联比较多的功能开始重构
• 代码实现简单的功能开始重构 -> 代码实现比较难的开始重构