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