从0到1经历的一次重构

一、为什么需要重构：

1、每次促销活动，波次服务几乎都会卡住，卡住的原因就是旧系统的各种bug且不好排查，影响了商品出库效率，毫不夸张的说每次大促就像是在打仗，出问题成为了家常便饭，见怪不怪。由于我们业务的特殊性，每个月都会经历一次促销，而作为仓储服务，用户在商城买了自己喜欢的商品就需要在仓库内找到指定的商品发给用户，这个过程在仓库内部我们称为捡货商品出库。为了提高捡货效率我们提供了一个仓储内波次服务，这个波次服务所做的工作就是快速在仓库内找到订单上的商品，这个过程我们称之为跑波次，每跑一次波次就会将当前订单上的商品在仓库内快速找到方便仓库内人员进行捡货出库。

2、排查问题的难度大大增加。原有的系统的业务代码是用python语言写的，而python丰富的语法糖加上开发时没有规则约束，导致原有的系统设计的五花八门，方法和函数之间调用关系很深，各种高端操作给排查问题和迭代需求带来了很大的阻力。

3、维护原有系统的人对于业务的熟悉程度不够。原有的系统由于公司的发展壮大、文档的缺失、人员的流动以及开发某个业务的人不固定导致了维护旧系统的人对于业务的熟悉程度存在大量盲区，几乎很少有人对于一个模块有一个很清晰的认识，认识程度大多数人几乎都是模模糊糊，而这又导致了迭代时出问题的概率大大增加，线上的问题频繁出现，尤其是促销期间，出库效率因为跑波次几乎每次都卡住而导致用户很不满意。

二、重构的方式：

我们重构是用go语言来代替python语言，重构有两种方式可供选择：第一就是按照模块进行重构、第二就是整体重构。

1、按照模块进行重构。

好处：风险可控、可以集中优秀的人员对于业务分优先级然后将业务按照优先级投入人力和时间来进行重构。

坏处：由于需要换开发语言，需要考虑开发语言之间的兼容性，需要考虑重构的模块和未重构的模块之间的兼容性，开发人员短期压力很大。

2、整体重构：

好处：不用考虑模块之间的兼容性，不用考虑开发语言之间的兼容性

坏处：风险不可控、上线压力很大。

三、重构遇到的问题：

排期的压力。由于我们是整体重构而且这次重构上边的大老板很重视，有上线时间和诸多里程碑。所以注定了，研发侧和产品侧的排期全部是倒排。在有限的时间下重构整个仓储系统。而制定这些里程碑和上线时间又是需要对于业务的熟悉程度很深才可以。否则一旦错估业务的复杂程度和实际执行人的业务熟悉程度以及开发质量就会导致很多问题。而恰好这些问题我们全遇到了，这次整体重构的人是慢慢补充上来的，而且大多数人之前都没有go语言的开发经验和相关的仓储业务经验。这些不利的条件几乎全踩雷了，这些现实的因素导致了研发侧的排期很不准，而这些排期又是倒排，一个排期不准又影响了下一个需求的研发。而值得吐槽的是关键是部分产品对于负责的业务也不是很熟悉，甚至将prd写成了ppt。这时研发侧只能依靠加班+熟悉原有的逻辑来满足现有的prd。

四、重构解决的问题：

五、有哪些可以吸取的经验：

1、想要重构成功，就需要充分调研原有的系统存在哪些问题，这时新的系统才可以对症下药，解决哪些问题，往往重构成功不是简单的换一种开发语言，而是做了很多努力。

2、前后端API交流的方式也发生了很大的变革。原有系统前端和后端人员API沟通方式是通过后端将链接贴在一个文档上。重构时前后端API服务，后端定义好接口生成指定文档返回默认值，部署好文档服务，前端去看文档即可，大大方便了前后端联调，前端可以不用等后端接口开发好再介入开发，因为开发刚开始就可以定好接口协议，然后实现了前后端开发的接耦。

3、我们沉淀了很多工具和组件。原先的系统工具很稀少且不统一，就比如上传Excel有的产品要求用户上传的Excel行数中可以有空格，有的产品要求不可以有空格，我们后端推动产品统一了这种方式。我们沉淀了进城内消息通知类似于kafka的功能可以通过异步调用实现业务接耦，也可以重试、开协程分批查询数据库、Excel的上传、下载导出的工具、批量插入和批量更新、操作集合的工具集。

4、虽然重构的人大多数不懂业务，并且之前没用过go的开发语言，但是我们有一个架构师是技术专家，来制定各种开发规范和解决开发中遇到的问题。

5、我们会议很多，每天都有进度会，我们对于代码的review要求提高了，对于开发制定了一个大体流程。首先是产品宣讲高阶方案、产品讲prd、后端反讲技术方案、测试讲测试用例。