目录结构：

一、啥是系统重构？ 二、为什么要系统重构？ 三、系统重构，要注意哪些点？ 四、该如何推动系统重构这件事？ 五、个人过往真实案例分享

前言：

SuperG同学的公司，最近在搞各种大翻修，但是同时里边的员工还要正常工作，于是就出现了：因为厕所要重建，所以要换楼层上厕所，因为楼梯要重修，所以只能用电梯。

导致中午去撒个尿，一趟要20多分钟，造孽啊~

一、系统重构是什么意思？

系统重构，就是结合业务现状，重新设计系统

并不是完全的从0到1，其实是从1到10的过程，既然老系统让公司业务正常运转了那么多年，肯定有其可取之处，千万不要全盘否定，而是要深挖业务，做好用户调研，保留重要的业务场景、流程，取其精华去其糟粕。

二、为什么要系统重构？

• 老了，跑不动了，年轻人~
• 各板块之间耦合关联性太深
• 很多功能已无法满足飞速发展的业务现状
• 已经在现有系统打了各种补丁，让系统变得越来越臃肿
• 很多业务流程非常长，牵一发而动全身
• 优化系统功能，已变得举步维艰，动哪块都感觉不自在不合理

三、系统重构，要注意哪些点？

1·结合各垂直事业部业务场景，梳理业务流程现状

先梳理业务流程现状，再结合现状提出可优化的流程点与业务协商，双方意见没冲突，那就可以往下推进。

梳理时，建议重点关注以下几点：

• 主要流程：先把当前主要大流程搞清楚，一般比较容易整理
• 正向流程：一件事情的正常流转
• 逆向流程：事情是同一件事，但往往是一些非常规流程更难处理
• 单业务流程：一个事业部，一个业务线的流程
• 多业务流程：一个事业部，多个业务线的流程
• 跨系统：从上游到下游，多系统之间的数据是如何流转的
• 跨模块流程：当前系统，不同模块之间数据是如何输入输出的

2·合理拆分，系统各板块功能边界

• 哪些属于基础主数据？
• 哪些属于公共功能？
• 哪些属于不同业务线功能？
• 前后端功能该如何拆分？
• 各模块之间如何关联？

3·逐层梳理产品架构

产品架构的本质：

是理解透彻如何挑出白萝卜、红萝卜，这些萝卜又应该分别放进哪个箩筐。

展示层：系统以什么样的形式给人使用？电脑桌面、浏览器、手机、ipad等。公司内部业务系统，一般是浏览器访问。

表现层：系统长什么样？也就是产品原型，菜单结构如何划分，页面功能解决什么问题？功能页面如何体现？业务流程该怎么走？等。

业务层：业务功能特性，整理各事业部的特色业务功能；你必须有，别的业务不需要。

随着时间的推移，会有不少中台层的功能变成业务层的功能；反之，业务层的功能很少会变成中台层的功能。为何？

因为随着公司的发展，各事业部的业务个性化需求会越来越明显，想去优化又因为是公共功能改不了，怎么办？只能从中台层剥离变成业务层特有功能。

中台层：共性功能，各事业部都需要的共有功能；你有我有全都有啊~

要想做好中台层的架构，首先得知道中台到底是什么？阿里官方的解释：“前台”就是贴近最终用户/商家的业务部门,包括零售电商、广告业务、云计算、物流以及其它创新业务等。

而“中台”则是强调资源整合、能力沉淀的平台体系,为“前台”的业务开展提供底层的技术、数据等资源和能力的支持,中台将集合整个集团的运营数据能力、产品技术能力,对各前台业务形成强力支撑；官方的解释是推出中台为了提升效率支撑前台业务的快速发展。

支撑层：辅助功能+对接的外部系统。比如：权限管理，销售平台对接，物流服务对接，沟通工具，等。

4·定义不改什么比要改什么更难

要改什么，咨询下业务体验下系统，画画流程图跑跑业务数据，一般都能发现。但是，哪些地方又不改，直接迁移到新系统呢？迁移之后，能否与新的业务模型，产品架构耦合呢？

不改的前提有三个，重点深度思考：能满足业务现状，业务比较喜欢这块功能，迁移到新系统风险比较小。

5·历史数据如何处理？

哪些数据是可以舍弃，哪些数据是当前就应该人工维护以便后期批量导入？

如果有些重要数据是不能舍弃，那么在做表结构设计的时候，就要考虑前后数据库表字段的兼容性。

要么在新表中的字段包含旧表必填字段，要么新旧表字段之间有一对一映射关系。

系统重构，数据库中大部分表必然要调整或者重新设计，但小部分表能保留的建议保留复用。

6·业务同事的对互联网软件的接受程度如何？

为何有此一问，举个例子，如果你的用户连英文都不会，你做个中英文双语系统；再比如，你的用户连电脑都不怎么会用，你却做了个系统，他们简单的操作一件事情，要跳转五六个页面。

你我都不是真实用户，不要把用户的水平想象的太高，这不是贬低而是真的换位思考。如果是以上这两种情况，前者英文版本去掉，后者将页面尽量做简洁，流程能合并的合并，说明该给就加粗放大提示清楚，他们在乎的不是页面丑不丑，而是页面少一点，流程简单一点，解释说明明显一点。

对于这类人，多做几次产品培训，保留好培训视频。老系统重构，在此问题上，永远不是他们的问题，而是你的耐心问题。

7·投入产出比

是否一定要重构系统，能否通过更低成本的业务培训或者优化当前系统解决现有问题，但凡有一点希望，我们都不要去贸然重构系统。

如果非改不可呢？那一定要先做好投入产出比的估算，改造老系统都是吃力不讨好的事情。做好了可能并不会获得多少表扬，做砸了就会有严重的后果，被辞退或者降职降薪。

这个应该是大佬们最关注的问题，要投入多少人天，花费多少时间、金钱，建议列个功能清单，将整个项目计划列一下，让大佬心中有数。

8·灰度测试环境数据是否完善

都要动刀了，结果连个测试的地方都没有肯定不行；为了以防万一，灰度测试环境的数据应该定期维护，尽量保持跟正式环境一致，但不用做到实时，一般一周更新同步一次即可

9·多跟业务、技术沟通

千万别他喵的闭门造车不懂装懂，记住一点，人家骂你蠢好过被辞退。你这不是改造系统，你这是在造定时炸弹。

开动之前，一定要先吃透系统现有的逻辑，不懂就问。页面、规则、流程我们一般都会去问。但是，小的点也不要放过，比如一些业务专有名词是什么意思。

10·立项之前产品内部先达成一致

先在产品团队内部消化掉自己能消化的所有问题后，再走出门对外沟通推进。

11·哪个地方先开刀？

识别可以最快可以独立重构的模块，搭好全局重构的优先步骤。一般对现有业务影响比较小的闭环功能，适合先搞起来。

12·不要影响现有业务正常运转

业务不可能等着你系统做好，系统无论如何重构优化都跟不上业务的发展速度，除非公司倒闭。

那么，结合这种现实情况，我们在做系统重构的时候，个人建议新旧系统双系统并行。老系统继续打补丁，新系统分好优先级按进度开发。

13·不要忽视权限管理的重要性

系统设计之初，一定要重视这块，虽属于基础支持层功能，但一旦系统使用的人越多这里存在的价值就体现的越大。

权限配置这块无非包含：公司组织架构管理，用户管理，角色管理，权限配置。大圈套小圈，最终实现一个用户可以拥有多个角色，一个角色可以有多个权限，一个权限可以分为按钮权限，数据权限等。

四、该如何推动系统重构这件事？

• 立项，拿着功能清单，让各方大佬签字画押
• 招人，重构非儿戏，找有相关项目经验的产品经理，开发等
• 宣讲，开会将完整的初步产品解决方案同步给项目组所有相关人
• 大佬，带头的梳理产品架构，技术架构，主流业务流程图等
• 分工，各小弟针对大佬的产品架构图，认领自己擅长或者感兴趣的模块
• 做事，使用模块化方法，画流程图画原型，将系统各板块高内聚低耦合；如果能力足够，可以为开发梳理产品信息结构图（约等于E-R实体关系图），这个有助于他们更好的做数据库表结构设计。
• 内部，产品团队内部，各小弟将自己画好的流程图、原型图汇总整合，跑通目前有考虑到的业务场景下的业务流程。
• 初审，跟业务对原型和流程，查漏补缺。这里主要关注，业务场景是否齐全，逆向流程是否有遗漏。
• 二审，跟开发团队对原型和流程，这里主要沟通原型规则，流程图
• 终审，叫上项目组所有成员，主要是让团队所有人信息同频，业务跟开发理解的是否一致。还有，强调清楚本项目所有风险点，避免后期踩坑。
• 概要设计/测试用例评审，也就是让技术反讲咱们的产品设计方案。背景、目的、了解清楚没，数据库表结构怎么设计，业务规则、流程有哪些等等。
• 开发测试都能讲清楚，接下来咱们产品的主要工作就变成保姆了。动不动就关怀嘘寒问暖一下，保证项目过程中正常推进即可。

五、采用模块化设计理念，重构商品模型

什么是模块化？让系统功能高内聚、低耦合、可复用、可扩展。

比如一个积木是一个节点，十个积木搭建成一个组合。这个组合可以单独拿出去用，可以和其他的组合继续组合，变形金刚里的大力神就是6个机器人组合的，就是模块化。