我以为重构这个坑太大了，所以就从十个偏历来说说，重构前到底有哪些点是值得留意的。

假如你没有做过重构，请看完这10个坑后保藏起来，下次要重构前翻出来再仔细看一遍，顺便给你的leader也看看；假如你正踩在重构的坑上，也请看完这些坑，那些还没踩的千万要留意了！假如你不幸和我一样做完了重构，来，我们握个手吧。

首先，我们明晰下重构这个界说：把之前的系统从里到外地从头做一遍，做完后就是2套独立不相干的系统，不是在之前的系统上部门重构，因为部门重构的坑还不足大。重构是因为之前的技能框架不能支持后续新成果的迭代了。

下面就来说说这10大坑吧！

设计不公道，改不改？

2年前我入职，任务就是重构系统，之前的产物司理不知道换了几多波，也没有留下完整的文档。要重构，必定要对老系统洞若观火啊，没步伐，我们只能先花2个星期的时间，把老系统的逻辑根基完整地梳理下来。

在一些业务流程方面，就发明许多不合乎逻辑的处所。好比药房退药今后，药品的状态不是已退药，而是又回到了上一步：待发药；治疗师已经开始治疗了，大夫还能把医嘱项删掉，这笔记录就溘然消失了；待收费的项目几天后就自动封锁了，这钱追不返来了……

作为一个严谨的产物司理，这些不公道必定要改！于是我就把退药后的状态改成了已退药，功效自家诊所的药师就炸了：“我药发出去今后才发明大夫开错了，把药拿返来让大夫改了从头发，你此刻退了药直接就是已退药，那大夫怎么改？”

我怎么会想到大夫总是会开错药呢，听完溘然心里怕怕的，退药不该该是患者不想要了吗？为了保持我之前完美的逻辑，我又加了个成果：退回修改。我预计其他诊所的药师看了这个按钮会有种莫名其妙的感受吧。

碰着这些不公道时，真的挺纠结的，之前的产物司理也不是傻子，存心弄个逻辑缺陷，必定是被客户逼的。但为了系统内成果逻辑的一致性和公道性，我们照旧改了之前不公道的处所，后头被吐槽也是在所不免的。

用户习惯怎么破？

上面也说到，我们重构的主要原因是：之前的技能框架太老，不能支持新成果的迭代。

但假如只是技能层面上去重做一套系统，视觉和交互体验上都没有改变的话，率领如何感知到我们团队的代价？技能是不能被直寓目到的对象，交互和视觉才是容易被感知到的对象。

我们常常看到的是C端产物，过段时间就换一套视觉气势气魄，并必然对用户友好，出格是一些低频的必需品，好比说手机银行，但这是能让率领秀业绩的好对象。

所以，重构Saas，视觉和交互必然要改！但我们只管不要改太多：

系统布局框架和页面上成果机关窜改不要太大，利便快速找到成果；

菜单和页面上的名词只管不要窜改，且各模块间保持一致；

交互形式和组件要全局统一的改，否则前后操纵纷歧致，用户利用时更懵。

我们真的不能太高估用户的电脑程度，好比说我们就改了个时间控件，他们就不会用了。

之前的时间控件是这样的，开始时间和竣事时间分隔选择：

此刻用的Element的组件，用户说怎么不能选一段时间了？本来他觉得是要双击选中，然后在一个日期上点了2次，就成了选中一天。

尚有很重要的一点，在用户切换系统前，请他们多利用新系统，直到能习惯，更好能较量纯熟地利用。否则事情一忙，系统又不会用，诉苦就更多了。

重构内容越做越多

Saas一般都不是一个单一的系统，他会有运营平台，尚有和外部的对接，好比公司内部其他业务的对接，第三方应用的对接。

我们原本只是想重构用户端的系统，其他都不动，但做着做着就发明，运营平台要重做，所有的外部对接也要重做，好比说聚合付出对接，检讨外送对接。事情量比之前预想的翻了一倍不止。

所以，在评估重构内容时，更好把所有和他相关的对象都捋一遍，固然想法很好，尽大概不改的就不要动，但要做好都重做一遍的规划。

成果必需>老系统才可推广

重构的系统和从0到1的系统，很大的区别是：商用时间差异，推广方案差异。