重构系统不得不考虑的两个问题

先讲结论：

公司之前的项目是一个大杂烩，多个业务放在一个项目中，多个网站也是放在一起，因为总是有一些共用的数据，结果导致很多工程师同事在一个项目上开发，之前大家开开心心和和睦睦，平安无事，但是随着业务越来越复杂，问题出现了：

共用的东西很多，牵一发动全身，经常出现修改一些东西需要在多个业务里面测试，因为没有写单元测试，就只能手动测试。

每个人写的代码参差不齐，某天你想重构一些代码，但你看看要改那么多地方，你就只能苦笑，结果就是破罐子破摔，就像有洁癖的人，只能捏子鼻子闭着眼睛生活。

所以今年7月份，我们启动了核心项目的重构，整体来说就是拆服务，写 API，用 API。今天我不讲整个过程是这么做的，我只分享重构前做的一些考虑，如果你也在做一些大的重构，希望这些考虑可以给你帮助。

项目重构可不单单只重构代码，这正是一个非常好的机会来重新梳理业务，可能你感觉业务跑的很顺，但是：

会不会有哪些业务已经是可有可无的状态？

会不会有哪个流程本来可以更简单？

会不会有一些遗留问题早就应该解决了，但是一直因为忙忙忙的缘故被拖后？

在重构的之前，技术人要完整的理解现有系统的结构，更重要的是要理解业务，尤其是要和第一线的业务人员进行沟通，了解他们的工作模式，了解他们的现有流程的一些困惑或难点。

了解清楚后，开始做减法，已经不需要的功能或流程要在老系统上进行精简或删除，可能你会问“我已经要重构了，为什么还需要在老系统上精简？“，因为你重构的系统还不知道什么时候上线呢，而且重构的系统再开发的时候需要参考老系统。

这一点是我考虑不足的地方，因为项目拉的比较长，时间预估方面也考虑不周，导致项目延期比较久。其中很重要的一个问题是：如何才能一步一步上线？

重构后的系统哪些部分可以先做完上线？让老系统与新系统的兼容工作分步做，而不是想着一步就全部替换掉，这不现实。

数据存储结构是否需要修改？如果修改，是否可以先洗一部分数据？

分步上线是把风险也分步，把风险分散开对一个成熟的业务非常关键。而且每一步都会给大家很多的信心，很清楚看到我们在前进，否则战线拉太长，大家都会觉得比较疲劳。

总体来说，这两点是在重构项目的时候大家都可以尝试考虑的问题，希望对你有帮助。