金马的Blog

我喜欢折腾

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

先讲结论:

  1. 老系统是否可以精简?
  2. 如何重构才可以一步一步上线?

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

  1. 共用的东西很多,牵一发动全身,经常出现修改一些东西需要在多个业务里面测试,因为没有写单元测试,就只能手动测试。
  2. 每个人写的代码参差不齐,某天你想重构一些代码,但你看看要改那么多地方,你就只能苦笑,结果就是破罐子破摔,就像有洁癖的人,只能捏子鼻子闭着眼睛生活。

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

一,老系统的业务是否可以精简或者删除?

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

  1. 会不会有哪些业务已经是可有可无的状态?
  2. 会不会有哪个流程本来可以更简单?
  3. 会不会有一些遗留问题早就应该解决了,但是一直因为忙忙忙的缘故被拖后?

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

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

二,如何重构才能一步一步上线?

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

  1. 重构后的系统哪些部分可以先做完上线?让老系统与新系统的兼容工作分步做,而不是想着一步就全部替换掉,这不现实。
  2. 数据存储结构是否需要修改?如果修改,是否可以先洗一部分数据?

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

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



本文链接: https://www.lijinma.com/blog/2017/01/18/two-questions-for-refactor/

显示评论