重构业务系统，我是这样做的

重构，是任何一个技术团队都无法绕过和回避的话题。

重构的原因有很多，可能是伴随着业务的发展与升级，系统无法快速支持需求迭代，这时就有了重构的念头，一般情况下不建议对老系统进行重构，毕竟重构是有代价的。

我最近参与了一个重构项目，接下来给大家分享下，我在重构业务系统过程中的经验总结。

1. 了解系统

接到重构任务后，不要立刻动手执行重构，而是对当前的业务流程和架构状态有个清晰的了解，如果开发过当前系统的同事还在公司，一定要拉着同事好好讨论。

我们要知道系统一定是给人用的，是给哪些人用的？不同的人使用系统的侧重点有哪些不同？他们使用系统主要是解决什么问题？这些问题我们一定要弄清楚。

要知道怎么给自己创建不同角色的用户，然后登录系统进行操作使用，如果涉及到了一些专有名词，一定要和团队成员沟通并达成一致。

2. 业务流程图

通过了解系统之后，清楚业务的核心流程，这时要按照理解绘制 业务核心流程图，这里面涉及到与各系统的交互，需要考虑跨系统之间的交互可否使用异步完成，尽量减少循环调用的情况，同时还要确定出当前系统的边界。核心流程图画好了，还要根据不同的业务分支绘制 业务各分支流程图。

这种图有很多工具都可以画，软件可以使用 EdrawMax，在线版可以使用 ProcessOn。

3. 业务功能模块图

根据业务流程图、业务各分支流程图，我们要确定出哪些功能模块？各功能模块之间是如何交互的？原来数据是如何存储的？根据以上问题，我们要绘制 业务功能模块图 ，然后再绘制 业务各模块详细图。

根据模块详细图，需要画出清晰的层次结构，梳理出 提供给他方的接口（约定接口名称） 和 依赖他方的接口，这时还要考虑规划出系统需要的基础服务功能，比如日志记录，监控预警等，然后根据功能点考虑分工，并评估出排期。

4. 约定时间

1. 接口文档约定完成时间
2. 开发完成时间
3. 联调完成时间
4. 自测完成时间
5. 提测时间
6. 上线时间

如果开发时间比较长，开发期间还要约定 “里程碑时间” ，整体采取前紧后松的节奏，先往前赶，保证在 “里程碑时间” 符合预期。

5. 约定规范

1. 编码规范
2. 代码管理规范
3. 例会规范（早、晚会制度）

例会规范，让项目人员轮流主持，鼓励每人发言，及时给予反馈。

6. 非技术问题

舒缓团队的压力，给予团队更多的鼓励，定期向团队同步状态，得到大家的理解和支持，还有一些无法把控的各系统间交互沟通，我们要做到与各对接方坦诚沟通。

7. 上线准备

上线前做好上线准备，充分准备出需要提前配置的东西，同时想好 B 方案。

8. 上线后复盘

这个点非常重要，总结这过程中的经验与不足，同时表扬大家做了一件很牛X的事情，团建一波 Happy 起来。

小结

以上，仅供参考。

上面的这个过程，其实是重点关注了 研发计划管理 和 研发项目管理 ，关于 研发质量管理 如果没时间的话，可以上线后再制定计划完善。