0X01

開始做一個app的時候，要先做的是流程設計與資料庫模型設計。

但做的模型設計往往是設定欄位滿足當前的需求，缺乏足夠的經驗，即使為以後的功能預留出位置，也無法考慮周全。

比如，剛開始做使用者表，關於刪除使用者的功能，一開始預想的是直接刪除使用者。等到所有功能做完了，這一個版本結束了，在下一個版本迭代中，想要給資料庫新增一個刪除status欄位，刪除的時候改status=0，用於標記刪除，代替直接刪除使用者，以記錄歷史使用者資料。

但是看了一遍程式碼，如果加多一個刪除的status欄位，需要考慮這個庫的各個使用的地方，是不是需要在增刪改查的時候加入status的判斷，會特別頭疼。

0X02

最近的一個需求是我需要做一個數據庫資料刪除的功能，但是刪除完又想有資料回滾、刪除資料記錄的功能；最好的應該是有一個刪除狀態，但是這個專案的所有功能邏輯其實我也並不是特別清楚，如果加一個狀態，需要先弄清80個使用該表的地方，再進行判斷是否需要改動，工作量實在是複雜。

反而是在刪除的時候同時插入另一個複製的表，很快就能做完回滾的功能。

前期的模型設計，後期要改動，成本實在是太大了。所以應該儘量在專案開始初期就做好資料庫模型的設計，還有功能的預留位置，就算現在版本比較簡單，也需要考慮以後迭代更新的時候可能會新增這個功能。儘量設計好一個足夠健壯健全的框架，以免迭代的時候還要回頭改動框架，那樣成本就太大了。這也是與經驗有關，但不要以經驗不足為藉口就不做了。經驗不足，調研輔助，思考為主。

0X03

另一個點是，在加狀態來判斷幾種狀態之前，先考慮一下，能不能從資料庫中的其他欄位中判斷出狀態的不同。

比如說，原本我這個表中只存廣東人，所以所有模型設計都是依靠廣東人的。之後需要加一個需求，東北人的資料也要接入這個表中。

其實加一個來源欄位是最科學的方法。但是如果可以從其他欄位，比如戶籍、戶口、住址、口音這些地方來判斷來源，那麼更容易做的是用其他欄位來判斷，加一個來源欄位實在是成本太高了，而且相比現有欄位判斷，顯得更加雞肋。

—————————做完了狀態判斷的流程後，發現有一個欄位可以很簡單的判斷，於是把之前的改動都刪除掉，再兩三句程式碼改完。當改完的時候有點想哭，記下來，長點腦子。