一，總體設計
1，系統間關聯應減少實時介面呼叫
外圍或者上游系統，很多應用以及介面依賴於很多下游系統，所以如果下游系統oom或者其他問題的時候，
會導致上游系統不可用，而很多上游系統又是直接面向使用者的，所以在設計上應該減少關聯和耦合。
方案：有很多資料可以通過非介面的方式，或者db同步，或者上游系統自行配製，比如保險的條款，產品的方案等不會經常變動
的資料，完全可以不用實時呼叫介面的方式，這樣減少了應用層次的關聯。
還有一點，就是注意快取的設計，最好實現快取機制，優先訪問自身系統的快取以降低呼叫次數
2，完善的防重複的機制
資金類的交易系統，下發財務或者送盤時需要進行防重複，避免重複扣款或者退款。
案例是防重複按照當天的日期來控制，當天傳送異常的確不能重**送了，但是第二條又可以重**送
方案：對於當天傳送異常的這種案件應該加乙個狀態，這種狀態應該特殊處理。
3，sql超長處理
很多spring框架的系統會設定sql的最大查詢個數是100000個，如果超長直接丟擲異常
方案：一般只有基礎資料才會出現這種情況，業務資料不太會出現，所以基礎資料新增的時候要注意看是否會超出最大個數
比如機構資料，二級**四級五級機構整個加起來很有可能超長的，所以新增資料要注意。
4，多執行緒注意點
（1）hashmap核心是陣列+鍊錶，長度可以動態變化，增長後會重新計算map裡面的key的hash值，所以會出現重新計算後
containskey是可以查到某個key的，但是get不到值
方案：使用concurrenthashmap代替hashmap，可以使用同步鎖
（2）******dateformat非執行緒安全，多執行緒出現衝突時，有可能丟擲numberformatexception
方案：在******dateformat物件上進行同步操作，確保該物件同時只有乙個日期轉換操作執行即可。
二，介面方面
1，查詢類頁面需控制查詢範圍
介面如果查詢的範圍沒有錄入，比如運營使用，拉取清單，容易導致查詢過慢，甚至全表掃瞄
方案：必須加上查詢條件，比如客戶號，或者查詢時間等
2，檔案目錄劃分需要選擇恰當的維度
上傳附件異常，發現nas其他地方可以直接上傳，最終發現是這個上傳的子目錄太多，導致ls打不開
方案：在nas上需要控制建立資料夾的數量，最好按天或者按不同業務型別這種可列舉的方式進行目錄儲存
3，合理設計和使用日誌功能
日誌過大，或者沒有打出日誌，都需要合理分配
方案:確保log4j.properties檔案沒有被打到ear包中
日誌可以考慮是否可配置成非同步寫日誌
定期清理系統的log
Android開發過程中需要注意的細節
git 使用 rebase 命令來合併分支，盡量不要直接 merge 導致分支 日誌混亂。開發新功能時，自己在本地建立 feature 分支開發，功能開發完畢之後，參照上面合併流程操作功能的合併，並刪除本地分支，注意不要將本地分支推送到伺服器。平時開發只在 develop 分支和自己的本地分支操作，...
開發過程中專案是否需要重構？又需要注意什麼？
重構是需要慎重考慮的，不是拍腦子決定的事情！程式設計師都有一顆工程師的心，所以當他們到一片新的場地想做的第一件事就是，將舊的一切推倒重來。是的，他們覺得舊 異常混亂，因為讀 更難，寧願丟掉舊 重新寫，也不願意修修補補，他們認為舊 簡直一團糟。我覺得這個出發點是好的，但我觀察了非常多的案子，那些重構的...
介面開發需要注意的
我們在開發 api 應該注意的幾個事項 僅供參考 1 單檔案實現多介面的形式有很多種，例如 if.elseif.或 switch 或 動態方法 也就是tp的這種訪問函式體的形式 2 對於資料的輸出最好用json，json具有相當強大的跨平台性，市場上各大主流程式語言都支援json解析，json正在逐...