多使用者環境下新手常犯的乙個錯誤

軟體開發人員參與的專案從單使用者單機版已經變成了多使用者環境了，很多新手並沒有真正理解多使用者環境下要注意的問題；經過一些實踐後基本都掌握了書寫**和開發的技巧，但有乙個錯誤出現的概率非常之大。

概括的說就是「認為任務所操作的資源是我獨佔的」。

下面舉乙個例子：如果有乙個業務它有三種狀態「a、b、c」，當業務處於a狀態時業務可以被刪除；開發刪除功能時，先從資料庫檢索a狀態的資料，並以列表方式顯示在螢幕上，選擇要刪除的資料，並在伺服器端執行刪除。

容易發生錯誤的地方：新手會將被選中資料的主鍵傳遞到伺服器端，並在伺服器端執行刪除時使用delete from *** where id = 'idparmater'；這樣做的問題就是，執行業務操作前資料狀態有可能發生變化而導致刪除了不允許刪除的資料。

為什麼新手這麼做呢？他的假設是從我顯示資料開始，資料沒有發生任何變化。

正確的是使用delete from *** where id = 'idparameter' and state = 'a'，這樣才能保證刪除的資料永遠處於a狀態。

更加普遍的問題是，大家最常碰到的修改資料時發生；我們從伺服器取得資料並在介面中修改資料，修改完後提交資料時，資料已經發生了變化。

原則：以業務目標為本，結合已經永久儲存的資訊和互動所得的資訊進行嚴格的處理，不要假設互動所得得資訊和永久儲存的資訊是一致的。

實現：前面提到的刪除是容易實現的，對於修改可能比較麻煩，有幾種辦法供參考 1、

記錄版本時間戳，給予每條資料乙個版本號時間戳，每次更新要比較我獲取資料時的時間戳，如果不一致表示我在互動期間，已經有人修改過資料。 2、

比較資料內容，就是進行修改時需要比較我取數時的內容和我更新時的內容要一致，這也是dataset自動處理更新時採用的辦法；這個辦法的優勢是可以部分控制版本，也就是只對我關注的部分而不是全部進行版本控制，劣勢是所需要的sql語句很麻煩需要相應的工具支援 3、

進行行鎖，使用資料庫行鎖是不現實的，只能使用應用級的行鎖；他的問題是異常情況需要進行維護性解鎖。

這麼囉嗦並不是要解決問題，是想強調必須要有乙個意識：我們編寫的這個功能點執行時所用的資料它不是靜止的，乙個業務單元存續期間資料內容可能已經發生了變化；任何時候都要有應付提交業務執行時變化的機制。

對於傳統多執行緒開發人員，資料也存在類似的問題，這方面的意識可能強點。

再次強調：這種原因導致的問題會比較隱蔽，除非測試人員很有經驗才能發現；很多時候表現為偶發性，而且同一問題表現多種多樣的現象，不去研究**很難發現問題的本質。

希望引起重視！！！少一點「不可能啊…. ,我這不能重現…」等等回答，這種回答有相當一部分是上面說的問題，你的開發**、測試建立在假設之上的，當然「不可能啊…. ,我這不能重現…」。