后端产品容易忽视的坑(二)

后端产品容易忽视的坑(二)

时间:2020-7-13 作者:抖音代运营

本文结合案例,聊两个小话题:

  1. 异步处理机制,会给脏数据带来可乘之机?
  2. 取“全部”,是否等同于遍历所有枚举值?

一、异步处理机制,是否会给脏数据带来可乘之机?

1. 场景

【商品列表】,以导入的方式新增商品,是很正常的一个功能。作为资料一部分,商品的图片,也可以导入。

方式就是在Excel录入图片的url地址。

机制就是:导入后,系统先打开地址,然后下载图片;下载成功,再上传到【商品列表】。

只是这个功能在机制上,往往要异步执行。因为解析url的时间太长。

于是,异步的实现手法,就可能导致bug的光临。案例如下:

2. 案例

和上述的场景相似,且规定了导入模板中,商品图片是必须项,所以未写入图片的时候商品数据不完整。

如果:

00:00的时候提交Excel,其中有商品编码001。

当时,检查到商品编码001在系统不存在,于是该数据等待异步执行。

而就在00:01的时候,(另一)用户手动创建了同一商品编码001,创建的时候系统验重通过(因为Excel导入的那个001还没执行写入)。00:02的时候Excel写入成功。此时,系统就会出现两个001商品编码。于是导致数据重复。

这里一个隐藏的不合理条件:就是导入的数据中无图片,则无资格参与去重。

这就是一个利用异步处理的时间窗,数据偷渡的现象。

3. 解析

这个失误的原因本质上,在于Excel的校验和执行之间,拖的时间太长,或者说,写入数据的时候没做校验。但是七十九度的需求到开发那里,这样实现的开发,没测到位的测试,绝对是有的。

七十九度的启发:

PRD中做提醒:

要尽量想在开发前面,因为开发也有不靠谱的。比如案例中的PRD,可以增加特别提醒,将可能的风险暴露。

方案根源避免:

比如案例中,要求在Excel导入的时候,图片未到位时,视为草稿状态写入数据库,占住商品编码的坑。那么,如果有同样的商品编码手动创建,就会当场检查到。从而避免异步的时间窗,引入不法数据。

二、取‘全部’与取每个枚举值的差别

1. 背景

O2O平台的门店商品,是商品编码个数n,乘以门店个数m的矩阵。表达的意思是,将某商品,铺货到某个门店中。

若某场景下,n个商品要铺货到所有门店,以导入方式执行。

那么导入Excel的表格中,就只需要录入n行商品数据,不必写具体的门店,而是定义:门店为空的,即为全部门店。

从而将数据量降维,减轻用户负担。

2. 案例

用户有1个商品,铺货到m个门店。那么导入表格中只写一行,门店列为空:要求系统对该商品铺货到所有门店。

开发的实现机制就是,发现门店列为空,则抓取所有门店,挨个执行铺货。

但是忽视一个问题:全部门店中,会有启用和禁用的门店(甚至更多关系)。

门店禁用之后,在数据库,还有这些门店与商品的绑定关系,只是前端页面没显示。

有数据,就有可能被新的逻辑运算引用(所见非所得)。

那么方案中就要做启用状态的过滤。

那么问题就是:你定义门店列为空的逻辑,是否可靠。

3. 分析

正常情况下,业务不这么单纯。用户录入指定门店的时候,一定是用户看得到的。而为空的时候,默认取全部,就意味着可能超出了用户的可控范围。

好比指定一个星球(火星、木星),和默认全部星球(认知边界之外的星球无法把控),是完全不一样的。

意识到这个问题之后,那么方案需要优化:

方案一:

在默认全部的基础上,增加限制,比如全部启用状态的门店。

优点:从逻辑层面是安全可靠的。

缺点:增加了一个非强逻辑的校验,因为可能转眼这个门店就启用了,那么又要重新处理。

方案二:

不允许用户将门店列留空。

若用户想对全部门店铺货,那么就录入全部门店,用逗号隔开。即多个门店写在一个单元格中。

类似的问题,在搜索项中也存在。比如搜索全部、该项不参与搜索、勾选全部枚举值,在某些具体环境下,是三种完全不同的结局。

#专栏作家#

唧唧歪歪PM,公众号:唧唧歪歪PM(ID:jjyypm),人人都是七十九度专栏作家。书籍《后端七十九度宝典》作者,药学硕士转行互联网产品多年;熟悉跨境电商业务,医药领域;擅长大型后台体系,社交APP。

本文原创发布于人人都是七十九度,未经作者许可,禁止转载

028-84360888 13608068886(推销勿扰) 发送短信