相信在产品经理的职业生涯中，大家不止一次听过系统重构这个词。
而且所有产品经理都经历过这样的魔幻时刻：明明只是加个筛选条件，技术评估却要3个月；想优化某个功能按钮，却被告知整个页面都要重写。
一问原因：因为要系统重构！
那到底什么是重构呢？
如果用一个我亲身经历过的例子来解释重构的重要意义就是：
我当年所在某电商平台在一次促销活动时，导致每秒峰值订单突破5000万时，订单系统响应速度从200ms骤升至2秒，注意是每单哦！
最后一番排查发现：优惠计算模块与库存模块存在循环调用，核心业务逻辑与日志模块深度耦合。
想象这样的场景：炒锅师傅（优惠模块）每做一份宫保鸡丁，都要跑到仓库（库存系统）确认花生库存，再折返调料台（日志系统）记录操作日志。高峰期这样的折返跑，不出餐慢才是奇迹。
同过这个做菜的例子大家很容易理解，这并不是因为软件设计失误，而是厨房（系统）扩张后的必然代价，单多了你就要优化的工序，要么加人要么提前做准备，相信没有人会去说厨师你怎么怎么样对吧？
不过很多时候，在我做咨询走访很多公司时，第一时间这个团队的信息化负责人的结论都是会把这个问题甩到“初代”产品经理身上，声称是“初代”系统的产品经理的设计不合理所导致了今天的一切。
但是我想说：重构系统是不可避免的！初期就没有几个客人的时候你要做一个航母出来也没有用啊？
那今天我就给大家盘点一下重构的触发条件（避免在规划会上被甩锅）：
01【产品驱动】功能叠加困境：新需求开发周期超过3个月
【大白话解读】你是一家卖烧烤的店，当某天老板让你推出酸菜鱼的时候，你要做的就是需要重建灶台，先把一部分烤炉改成煤气灶。
02【产品驱动】协作效率低下：跨团队需求需修改5个以上模块，这背后往往是领域划分不到位。
【大白话解读】三个厨师挤在一个灶台炒菜，你觉得会不会打架？
03【技术驱动】系统性能瓶颈：核心接口成功率低于99%
【大白话解读】相当于厨房出餐错误率超过10%
那我们要如何处理系统重构呢？
实时上按照现在企业的要求：重构就像在一家正常营业的餐厅去升级后厨——客人们照常吃着火锅，后厨却在悄然更换排风系统。
所以要求我们决不能停机！为此具体的执行步骤可以定义为下面的三大部分：
Step1：先搭临时灶台（顾旧立新）
在后厨角落搭建一个新的煤气灶，保持老系统不再迭代，在旁边根据新的产品规划重新设计整个功能并实现。
Step2：食材统一分装（接口翻译层）
老顾客依然要吃到熟悉的"麻辣香锅"，即便后厨已经改用智能炒菜机。
我们知道很多时候在重构的时候由于新的方案的应用，比如用户希望取消早已经不用的某个字段，很多老系统的交互还是用生成一个文件的形式定时去查询（很多银行系统现在还是这样）。
注意这个时候我们要做的是必须保证提供的数据消费方式和命名方式都是之前的（比如之前叫userID），我们要做的是必须额外建设一个新的翻译模块，把所有新的数据格式与接口翻译成之前的模式，这么做的最重要一点是，避免当某天下游报错的时候，别人可以直接把一本糊涂账扔到你头上，都是因为你重构系统导致的，我数据都乱了（别问我怎么知道的，血和泪换来的）。
Step3：动线魔法改造（数据双写+灰度发布）
就像在传菜通道加装自动分拣机，先让新模块处理5%的流量，同时保持老系统运转。当新模块的到达率稳定在99.97%后，才逐步关闭老旧代码。
所以总结一下就是：
盖新屋子：保持老房子对外输出不变，在旁边另起炉灶；
保持对外输出不变：翻译成现有接口的输出格式：字段叫法/字段类型/消费方式；
灰度切换流量：逐步将老系统的流量切换至新系统，最后关停老系统；
当然在文章的最后结尾，必须给大家补充一个我的经验教训：
重构这件事在任何一家公司都是出力不讨好的事，活又多，风险又高，如果你不幸接手了，那你要做的必须要让你的业务可感知，也就是通过重构给业务侧带来新的业务价值提升（速读/解决旧历史问题/解决之前业务不能实现的需求），否则重构的过程就将无比艰难！
下次再听到"需要重构"时，请记住：这不是在否定你的设计，而是邀请你参与指挥一场厨房革命。毕竟，在数字化生存时代，不会用架构思维武装自己的产品经理，终将成为被重构的对象。
