小經驗總結

1：存儲編號和名稱

通常狀況下，機構名稱會變動，而機構編號是人爲設定的，不易變動，存儲DB時，若是存儲了機構名，那麼當機構名變動時，很難修改，特別是數據量大的時候，若是僅僅存儲編號，經過關聯機構表就能夠獲取到最新的名稱。

上傳文件時，存儲文件路徑也存在相似的問題，能夠經過獲取文件根路徑，存儲子路徑和存儲文件名來拼接文件實際的路徑（或者url調用路徑）

2：修改多流程對象

採起備份還原策略

對於一條須要審批的記錄，須要審批結束後才能生效。那麼當第一次審批經過後，變成生效記錄。那麼當對此條記錄進行修改時，就存在問題了，是否在原審批經過的記錄上修改？若是是的話，那麼修改到一半，或者修改以後審批不經過，都會致使原生效記錄數據被污染，難以恢復。

因此就要採起備份策略，當修改生效記錄時，先生成一條備份記錄，後續修改就在此備份記錄上操做，若是修改未完畢或者修改後審批不過，則不影響原生效記錄~！若審批經過，則將原生效記錄變爲備份記錄，此備份數據變爲生效記錄！

 

3：ABTest設計

當APP端須要評估多個方案效果時，能夠將多個（好比AB兩個）方案分別作好，針對不一樣的用戶投放，最後採集數據肯定AB兩種方案哪一種效果更好。

4：預發佈設計

白名單發佈

5：APP端排版採起zone配置

經過cms配置APP端的排版要素，包括名稱，簡介，圖片，跳轉連接，其餘文字介紹，標籤信息，排序，埋點等等信息。。。

6：top sql監控優化

sql監控

7：白名單黑名單

當某功能發佈生產環境的時候，對此功能的屏蔽能夠採起白名單的方式，只有在白名單中的用戶才能看到信的功能，能夠用戶生產體驗。

黑名單反之~！

8：任務管理

略

9：統一圖片校驗及上傳

將上傳圖片的校驗解耦，建立規則表，不一樣的上傳處生成不一樣的校驗規則，那麼每一個上傳檢驗均可以自主配置，注意單圖，多圖上傳的校驗，注意擴展。

圖片通常的校驗：圖片類型，圖片大小，圖片寬高，圖片比例，圖片數量。。。

10：大文件上傳切分及保存

使用統一的上傳文件處理，主要是利用linux服務的命令行對文件進行去重，切分處理。再加上線程調度統一獲取處理。

11：簡單的uuid先鎖表後獲取

 

12：接口（HTTP）冪等特性

能夠利用ajax發起異步請求，從服務器獲取惟一的guid，而後真正的請求經過此guid來保證請求的惟一性，保證請求不會重複，特別是扣款，發送積分優惠劵等新增，修改操做·！

13：預定配置

正如上面的zone配置，能夠配置預定生效時間，好比配置xxx年1月1日開始生效，1月15日失效，那麼當元旦到來時，APP能夠自動切換預定顯示的內容，直到1月15日再切換回去。這種設置能夠預先設置，不用等到假期來臨了再臨時設置。特別是當這種操做須要審批時，因爲審批經過的時間不肯定，展現的內容不能依賴審批時間，可讓領導提早審批經過，後續自動展現