正文
开始想聊这个话题的时候，我是打算放弃的；因为这个话题涉及范围之广，内容之多， 让我犯怵；
近几年，待过两家公司；一家经历过重构，另一家也打算重构......
其实要下定决心，推翻重来，是一个很有勇气的决定；
归根结底，不到万不得已，谁想这么玩，谁愿意花费大精力去做这些脏活、累活；
所以究其原因，也只能说是一种综合因素吧，就像古话说的，天时、地利、人和；
至于为什么这是个很有勇气的决定，因为做重构这事的团队风险极高；上至业务高层，下至底层码农，都有可能一个不小心就被刀；
我曾经待过的一个团队，经历过一次重构，不过那是一次失败的经历；
开发预估了两个多月的时间，业务大佬决定，期间直接对新需求停滞；但是，最终上到生产的系统，老问题还在，然后又多了很多的新问题；
再后来啊，业务大佬和技术主管都被刀了；然后系统回退成老版本，重新承接新需求，并且开发时间被严重压缩，导致技术部门没日没夜的加班；
下面，我大致做了归档和整理，从这八个方面重新聊一聊系统重构；
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/ruoyi-vue-pro
-
视频教程：https://doc.iocoder.cn/video/
【重构原因】
其实上面也提到过，这是一个综合因素，可能是各种各样的因素叠加，造成一个不得不重构的结果；
下面，聊一聊我所碰到过的因素；要是没聊到的地方，也欢迎大家补充；
第一个
，可以归结为系统的稳定性或可用性：不管吹得怎么天花乱坠，你的系统总要可用吧，所以说可用和稳定是一个系统的最基本要求。开发一个需求还要全服务停用吗？业务量增长，系统还能抗下所有吗？那么问题来了，怎么保证可用和稳定？
首先，如果你是单服务系统，那么为了保障可用和稳定，需要对服务进行扩展，加入更多的机器来分担系统的性能压力，也就是常说的“服务集群”；
但是，往往我们的系统并不是单服务的，也就是我们常说的分布式微服务；这种情况下，就不得不扯到分布式的三大法宝：限流、熔断、缓存。相信要实现这三个法宝，有很多成熟的框架和工具等，这里就不过多阐述了；
第二个
，开发规范问题：这也考验了团队leader对底下成员的约束力，以及是否存在代码review的环节；
假设一个团队，leader确实没有对成员强制约束开发规范，更别提代码的review了；最终导致的问题就是，各写各的，每个人都有自己的一套开发习惯和开发规范；最终就是一个大写的“乱”；
这样日积月累，一代目埋坑，一代目撤，二代目上，二代目撤...... 系统不知道经了多少开发人员的手，最终，新入职的冤种某天需要排查一个产线问题，仿佛误入了代码的迷宫，深陷其中，无法自拔；
第三个
，推翻原先核心业务，重立新规：这个要解释起来比较麻烦，也碰到会比较少，然而，我恰恰就遇到了；
某天，业务大佬宣布，目前做的这套业务规则要被废弃了，他们重新拟定了一套全新的规则，意味着先前不知道几手的代码已经失去意义了，几乎90%都需要重新写；
都到这一步了，那就大刀阔斧的改革吧；出事了，emmm，业务的锅；
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
-
项目地址：https://github.com/YunaiV/yudao-cloud
