编辑导读:后端产品在工作中经常会遇到一些坑,稍不留神就很容易“入坑”了。本文作者基于自己的工作经验,围绕两个小话题展开介绍,希望对你有帮助。
本文结合案例,聊两个小话题:
【商品列表】,以导入的方式新增商品,是很正常的一个功能。作为资料一部分,商品的图片,也可以导入。
方式就是在Excel录入图片的url地址。
机制就是:导入后,系统先打开地址,然后下载图片;下载成功,再上传到【商品列表】。
只是这个功能在机制上,往往要异步执行。因为解析url的时间太长。
于是,异步的实现手法,就可能导致bug的光临。案例如下:
和上述的场景相似,且规定了导入模板中,商品图片是必须项,所以未写入图片的时候商品数据不完整。
如果:
00:00的时候提交Excel,其中有商品编码001。
当时,检查到商品编码001在系统不存在,于是该数据等待异步执行。
而就在00:01的时候,(另一)用户手动创建了同一商品编码001,创建的时候系统验重通过(因为Excel导入的那个001还没执行写入)。00:02的时候Excel写入成功。此时,系统就会出现两个001商品编码。于是导致数据重复。
这里一个隐藏的不合理条件:就是导入的数据中无图片,则无资格参与去重。
这就是一个利用异步处理的时间窗,数据偷渡的现象。
这个失误的原因本质上,在于Excel的校验和执行之间,拖的时间太长,或者说,写入数据的时候没做校验。但是产品经理的需求到开发那里,这样实现的开发,没测到位的测试,绝对是有的。
产品经理的启发:
PRD中做提醒:
要尽量想在开发前面,因为开发也有不靠谱的。比如案例中的PRD,可以增加特别提醒,将可能的风险暴露。
方案根源避免:
比如案例中,要求在Excel导入的时候,图片未到位时,视为草稿状态写入数据库,占住商品编码的坑。那么,如果有同样的商品编码手动创建,就会当场检查到。从而避免异步的时间窗,引入不法数据。
O2O平台的门店商品,是商品编码个数n,乘以门店个数m的矩阵。表达的意思是,将某商品,铺货到某个门店中。
若某场景下,n个商品要铺货到所有门店,以导入方式执行。
那么导入Excel的表格中,就只需要录入n行商品数据,不必写具体的门店,而是定义:门店为空的,即为全部门店。
从而将数据量降维,减轻用户负担。
用户有1个商品,铺货到m个门店。那么导入表格中只写一行,门店列为空:要求系统对该商品铺货到所有门店。
开发的实现机制就是,发现门店列为空,则抓取所有门店,挨个执行铺货。
但是忽视一个问题:全部门店中,会有启用和禁用的门店(甚至更多关系)。
门店禁用之后,在数据库,还有这些门店与商品的绑定关系,只是前端页面没显示。
有数据,就有可能被新的逻辑运算引用(所见非所得)。
那么方案中就要做启用状态的过滤。
那么问题就是:你定义门店列为空的逻辑,是否可靠。
正常情况下,业务不这么单纯。用户录入指定门店的时候,一定是用户看得到的。而为空的时候,默认取全部,就意味着可能超出了用户的可控范围。
好比指定一个星球(火星、木星),和默认全部星球(认知边界之外的星球无法把控),是完全不一样的。
意识到这个问题之后,那么方案需要优化:
方案一:
在默认全部的基础上,增加限制,比如全部启用状态的门店。
优点:从逻辑层面是安全可靠的。
缺点:增加了一个非强逻辑的校验,因为可能转眼这个门店就启用了,那么又要重新处理。
方案二:
不允许用户将门店列留空。
若用户想对全部门店铺货,那么就录入全部门店,用逗号隔开。即多个门店写在一个单元格中。
类似的问题,在搜索项中也存在。比如搜索全部、该项不参与搜索、勾选全部枚举值,在某些具体环境下,是三种完全不同的结局。
唧唧歪歪PM,公众号:唧唧歪歪PM(ID:jjyypm),人人都是产品经理专栏作家。书籍《后端产品经理宝典》作者,药学硕士转行互联网产品多年;熟悉跨境电商业务,医药领域;擅长大型后台体系,社交APP。
本文原创发布于人人都是产品经理,未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议