【重构】老系统重构指南
概述
系统重构是结合当前业务现状，对系统进行重新设计的过程。这并不是完全从零开始，而是从现有基础向更高水平迈进的过程（从1到10）。
老系统能够支撑公司业务多年，必然有其可取之处，重构时千万不要全盘否定，而是要深入挖掘业务价值，做好用户调研，保留关键的业务场景和流程，取其精华，去其糟粕。
重构原因
性能老化：系统已经“跑不动”了，无法满足当前需求，亟需引入年轻化的技术和架构。
模块耦合过深：各板块之间耦合性过强，关联复杂，导致维护和扩展困难。
功能落后：许多功能已无法适应业务的飞速发展，存在明显的瓶颈。
系统臃肿：长期以来的各种补丁堆叠，让系统变得越来越复杂和难以管理。
流程冗长：业务流程繁杂且冗长，稍作调整就可能引发连锁反应。
优化困难：系统功能优化举步维艰，任何改动都显得不合理或不自在。
操作
结合各垂直事业部业务场景，梳理业务流程现状
先梳理业务流程现状，再结合现状提出可优化的流程点与业务协商，双方意见没冲突，那就可以往下推进。
梳理时，建议重点关注以下几点：
主要流程：先把当前主要大流程搞清楚，一般比较容易整理
正向流程：一件事情的正常流转
逆向流程：事情是同一件事，但往往是一些非常规流程更难处理
单业务流程：一个事业部，一个业务线的流程
多业务流程：一个事业部，多个业务线的流程
跨系统：从上游到下游，多系统之间的数据是如何流转的
跨模块流程：当前系统，不同模块之间数据是如何输入输出的
系统功能边界拆分
基础主数据
指的是跨业务模块且较为稳定的数据，通常为系统的核心支撑。例如：用户信息、产品信息、客户信息、地理信息、系统配置等。
公共功能
系统中多个模块共享的功能，通常与核心业务无关，但对系统的正常运行至关重要。例如：用户认证、权限管理、日志记录、消息队列、邮件通知等。
不同业务线功能
为特定业务线定制的功能模块，通常依赖于具体的业务流程和需求。例如：订单管理、库存管理、财务管理、CRM、供应链管理等。
前后端功能拆分：
前端：负责用户界面展示、用户交互、数据展示等。 后端：负责业务逻辑、数据处理、API 提供等。
模块关联
各模块之间通过明确的接口进行数据交换和功能调用，通常通过同步API或异步消息进行通信，并保证模块间低耦合、数据共享。
逐层梳理产品架构
是理解透彻如何挑出白萝卜、红萝卜，这些萝卜又应该分别放进哪个箩筐。
展示层：
形式：用户通过何种设备访问系统（如电脑桌面、浏览器、手机、平板等）。 公司内部业务系统：通常通过浏览器进行访问。
表现层：
外观与布局：系统界面的设计、产品原型、菜单结构、页面功能等。 业务流程：各个功能页面的作用和流程如何引导用户完成任务。
业务层：
特色业务功能：针对各个事业部的独特需求，定义业务功能。 演变：随着时间推移，中台层的共性功能会转移到业务层，而业务层功能则较少转变为中台层功能，因为业务需求会越来越个性化。
中台层：
共性功能：所有事业部共享的功能，如资源整合、技术和数据能力支持。 支撑作用：中台为前台业务提供底层支持，促进前台业务的高效发展。 定义：中台强调的是跨部门的资源共享与能力沉淀。
支撑层：
辅助功能：对接外部系统和服务，如权限管理、平台对接、物流服务等。 对接系统：如销售平台对接、沟通工具等。
定义不改什么比要改什么更难
在进行系统迁移时，需要平衡“改进”和“迁移”的决策。以下是判断哪些部分应该改进、哪些可以直接迁移的标准：
需要改进的地方：
- 业务体验：通过与业务人员沟通，理解当前系统的痛点，画出流程图、跑业务数据，通常能发现需要改进的环节。
- 用户反馈：用户的使用体验差，或者某些功能频繁出现问题，这些部分通常需要优化。
- 业务需求变化：随着公司业务发展，旧系统无法满足新的业务需求时，需对相关功能进行改进。
可以直接迁移的部分：
- 满足现有业务需求：如果某些功能当前完全能够满足业务的核心需求，并且没有明显的优化空间，可以考虑直接迁移。
- 业务喜欢的功能：一些功能当前非常符合业务需求并且得到广泛使用，若用户和业务部门非常喜欢这些功能，直接迁移到新系统能够减少迁移的阻力。
- 低风险迁移：对于迁移后风险较小的功能，如无较大改动的核心模块，或者通过中间层进行兼容的功能，可以选择迁移。
迁移后的耦合问题：
- 与新业务模型兼容：迁移后的功能必须能够与新系统的业务模型、产品架构兼容。即便不修改某些功能，也应考虑它们是否能够在新的架构下顺利运行。
- 架构兼容性：需要确保旧功能在迁移后不会引入技术债务，确保与新架构的无缝对接，不会产生过多的耦合问题。
迁移前提的三个重点
- 能满足当前业务现状：迁移后功能必须继续符合业务当前的需求，不能影响业务的正常运行。
- 业务认可度较高：功能是业务所认可并广泛使用的，不需要过多修改就能迁移。
- 迁移风险较小：迁移过程中的技术风险低，能够顺利过渡至新系统，确保业务持续运行不受影响。
历史数据如何处理
哪些数据是可以舍弃，哪些数据是当前就应该人工维护以便后期批量导入？
如果有些重要数据是不能舍弃，那么在做表结构设计的时候，就要考虑前后数据库表字段的兼容性。
要么在新表中的字段包含旧表必填字段，要么新旧表字段之间有一对一映射关系。
系统重构，数据库中大部分表必然要调整或者重新设计，但小部分表能保留的建议保留复用。
业务同事的对互联网软件的接受程度如何？
为何有此一问，举个例子，如果你的用户连英文都不会，你做个中英文双语系统；再比如，你的用户连电脑都不怎么会用，你却做了个系统，他们简单的操作一件事情，要跳转五六个页面。
你我都不是真实用户，不要把用户的水平想象的太高，这不是贬低而是真的换位思考。如果是以上这两种情况，前者英文版本去掉，后者将页面尽量做简洁，流程能合并的合并，说明该给就加粗放大提示清楚，他们在乎的不是页面丑不丑，而是页面少一点，流程简单一点，解释说明明显一点。
对于这类人，多做几次产品培训，保留好培训视频。老系统重构，在此问题上，永远不是他们的问题，而是你的耐心问题。
投入产出比
是否一定要重构系统，能否通过更低成本的业务培训或者优化当前系统解决现有问题，但凡有一点希望，我们都不要去贸然重构系统。
如果非改不可呢？那一定要先做好投入产出比的估算，改造老系统都是吃力不讨好的事情。做好了可能并不会获得多少表扬，做砸了就会有严重的后果，被辞退或者降职降薪。
这个应该是大佬们最关注的问题，要投入多少人天，花费多少时间、金钱，建议列个功能清单，将整个项目计划列一下，让大佬心中有数。
灰度测试环境数据是否完善
都要动刀了，结果连个测试的地方都没有肯定不行；为了以防万一，灰度测试环境的数据应该定期维护，尽量保持跟正式环境一致，但不用做到实时，一般一周更新同步一次即可
多跟业务、技术沟通
开动之前，一定要先吃透系统现有的逻辑，不懂就问 (你这不是改造系统，你这是在造定时炸弹。)。页面、规则、流程我们一般都会去问。但是，小的点也不要放过，比如一些业务专有名词是什么意思。
立项之前产品内部先达成一致
先在产品团队内部消化掉自己能消化的所有问题后，再走出门对外沟通推进。
哪个地方先开刀？
识别可以最快可以独立重构的模块，搭好全局重构的优先步骤。一般对现有业务影响比较小的闭环功能，适合先搞起来。
不要影响现有业务正常运转
业务不可能等着你系统做好，系统无论如何重构优化都跟不上业务的发展速度，除非公司倒闭。那么，结合这种现实情况，我们在做系统重构的时候，个人建议新旧系统双系统并行。老系统继续打补丁，新系统分好优先级按进度开发。
不要忽视权限管理的重要性
系统设计之初，一定要重视这块，虽属于基础支持层功能，但一旦系统使用的人越多这里存在的价值就体现的越大。权限配置这块无非包含：公司组织架构管理，用户管理，角色管理，权限配置。大圈套小圈，最终实现一个用户可以拥有多个角色，一个角色可以有多个权限，一个权限可以分为按钮权限，数据权限等。
推动系统重构
立项：拿着功能清单，让各方大佬签字画押
招人：重构非儿戏，找有相关项目经验的产品经理，开发等
宣讲：开会将完整的初步产品解决方案同步给项目组所有相关人
大佬：带头的梳理产品架构，技术架构，主流业务流程图等
分工：各小弟针对大佬的产品架构图，认领自己擅长或者感兴趣的模块
做事：使用模块化方法，画流程图画原型，将系统各板块高内聚低耦合；如果能力足够，可以为开发梳理产品信息结构图（约等于E-R实体关系图），这个有助于他们更好的做数据库表结构设计。
内部：产品团队内部，各小弟将自己画好的流程图、原型图汇总整合，跑通目前有考虑到的业务场景下的业务流程。
初审：跟业务对原型和流程，查漏补缺。这里主要关注，业务场景是否齐全，逆向流程是否有遗漏。
二审：跟开发团队对原型和流程，这里主要沟通原型规则，流程图
终审：叫上项目组所有成员，主要是让团队所有人信息同频，业务跟开发理解的是否一致。还有，强调清楚本项目所有风险点，避免后期踩坑。
概要设计/测试用例评审：也就是让技术反讲咱们的产品设计方案。背景、目的、了解清楚没，数据库表结构怎么设计，业务规则、流程有哪些等等。
开发测试都能讲清楚，接下来咱们产品的主要工作就变成保姆了。动不动就关怀嘘寒问暖一下，保证项目过程中正常推进即可。
采用模块化设计理念，重构商品模型
什么是模块化？让系统功能高内聚、低耦合、可复用、可扩展。 比如一个积木是一个节点，十个积木搭建成一个组合。这个组合可以单独拿出去用，可以和其他的组合继续组合，变形金刚里的大力神就是6个机器人组合的，就是模块化。