記一次bug修復過程

個人建議，究竟有誰會看，以個人位置，到底能推進到哪一層
可行性，可能性

問題：
用戶的數據丟失了。覺得是修改操做 有bug，但查看了後端接口和前端校驗，都沒有發現問題。
可是input數據沒有日誌【日誌級別是debug】，不能自證清白。
而且一些沒有辦法輕易證實的猜想也有：是否是併發問題，一個insert操做操做剛完成，另外一個請求上來了，把這個新insert的數據刪除了。查了api網關，真找到有兩個觸發時間比較接近的兩個請求 。。。
糾結中：這個簡單的邏輯，還出問題，以爲很不爽，也不服氣。

tips:這種狀況下，可使用這種話術----」我先看一下「   若是直接說」這麼接口這麼簡單，怎麼可能有問題「 ---------------提出bug的人，可能以爲本身提出的判斷或事實，被否認了。
            


解決辦法：
是修改接口被誤用，在別的場景中被調用了

 

 

背景： 需求描述

有一個 一個頁面添加多個項的操做，
而且支持對多個項 進行 修改， 刪除幾個原有的，再新增幾個

方案1：對已有id的更新，對沒有id的進行insert ，還有對 刪除項 進行刪除-----這個貌似是最好的。略有複雜
刪除，若是使用邏輯刪除，則在 新增的記錄 時，要不要和已有刪除項的數據進行對比呢，若是已存在，則更新老的標識位，讓其可見便可------ 問題：怎麼斷定是一條相同的記錄呢。特別是字段比較多的場景

方案1：先刪再增
是邏輯刪，仍是物理刪除。

能夠邏輯刪，但要定時清表。對於操做頻繁的表，數據量會愈來愈多

問題：
一個接口有變動，但接口沒有按 單一職責 進行設計，調用散落在了不一樣的業務點。 
思考--對一個表不一樣字段的修改，可能會用於不一樣的場景。 看到有很多地方是處處使用這個接口，這就形成 參數校驗會散落在各個場景
一個對錶的修改操做