重构，是任何一个技术团队都无法绕过和回避的话题。
重构的原因有很多，可能是伴随着业务的发展与升级，系统无法快速支持需求迭代，这时就有了重构的念头，一般情况下不建议对老系统进行重构，毕竟重构是有代价的。
我最近参与了一个重构项目，接下来给大家分享下，我在重构业务系统过程中的经验总结。
1. 了解系统
接到重构任务后，不要立刻动手执行重构，而是对当前的业务流程和架构状态有个清晰的了解，如果开发过当前系统的同事还在公司，一定要拉着同事好好讨论。
我们要知道系统一定是给人用的，是给哪些人用的？不同的人使用系统的侧重点有哪些不同？他们使用系统主要是解决什么问题？这些问题我们一定要弄清楚。
要知道怎么给自己创建不同角色的用户，然后登录系统进行操作使用，如果涉及到了一些专有名词，一定要和团队成员沟通并达成一致。
2. 业务流程图
通过了解系统之后，清楚业务的核心流程，这时要按照理解绘制 业务核心流程图，这里面涉及到与各系统的交互，需要考虑跨系统之间的交互可否使用异步完成，尽量减少循环调用的情况，同时还要确定出当前系统的边界。核心流程图画好了，还要根据不同的业务分支绘制 业务各分支流程图。
这种图有很多工具都可以画，软件可以使用 EdrawMax，在线版可以使用 ProcessOn。
3. 业务功能模块图
根据业务流程图、业务各分支流程图，我们要确定出哪些功能模块？各功能模块之间是如何交互的？原来数据是如何存储的？根据以上问题，我们要绘制 业务功能模块图 ，然后再绘制 业务各模块详细图。
根据模块详细图，需要画出清晰的层次结构，梳理出 提供给他方的接口（约定接口名称） 和 依赖他方的接口，这时还要考虑规划出系统需要的基础服务功能，比如日志记录，监控预警等，然后根据功能点考虑分工，并评估出排期。
4. 约定时间
- 接口文档约定完成时间
- 开发完成时间
- 联调完成时间
- 自测完成时间
- 提测时间
- 上线时间
如果开发时间比较长，开发期间还要约定 “里程碑时间” ，整体采取前紧后松的节奏，先往前赶，保证在 “里程碑时间” 符合预期。
5. 约定规范
- 编码规范
- 代码管理规范
- 例会规范（早、晚会制度）
例会规范，让项目人员轮流主持，鼓励每人发言，及时给予反馈。
6. 非技术问题
舒缓团队的压力，给予团队更多的鼓励，定期向团队同步状态，得到大家的理解和支持，还有一些无法把控的各系统间交互沟通，我们要做到与各对接方坦诚沟通。
7. 上线准备
上线前做好上线准备，充分准备出需要提前配置的东西，同时想好 B 方案。
8. 上线后复盘
这个点非常重要，总结这过程中的经验与不足，同时表扬大家做了一件很牛X的事情，团建一波 Happy 起来。
小结
以上，仅供参考。
上面的这个过程，其实是重点关注了 研发计划管理 和 研发项目管理 ，关于 研发质量管理 如果没时间的话，可以上线后再制定计划完善。
