後端產品容易忽視的坑（二）
編輯導讀：後端產品在工作中經常會遇到一些坑，稍不留神就很容易“入坑”了。本文作者基於自己的工作經驗，圍繞兩個小話題展開介紹，希望對你有幫助。
本文結合案例，聊兩個小話題：
- 異步處理機制，會給髒數據帶來可乘之機？
- 取“全部”，是否等同於遍歷所有枚舉值？
一、異步處理機制，是否會給髒數據帶來可乘之機？
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。
本文原創發佈於人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基於CC0協議
