后端产品容易忽视的坑（二）
本文结合案例，聊两个小话题：
- 异步处理机制，会给脏数据带来可乘之机？
- 取“全部”，是否等同于遍历所有枚举值？
一、异步处理机制，是否会给脏数据带来可乘之机？
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。
本文
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
