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