對接實體的命名規範
依賴阿里雲的代碼規約 https://download.csdn.net/download/u013642886/12375553
關鍵步驟需要註解標明
一句話說就是要在寫的每一個方法中取其精華去其糟粕。
- 每個方法中儘量將組裝部分和執行部分抽離，複雜的執行考慮封裝和抽取
- 多關注現在開源項目中的一些代碼實現，遇到好的想法多多跟進和學習，慢慢積累經驗具備一定的前瞻性和擴展思維。
- 對代碼有一定的情懷，喜歡代碼不斷優化。這個在後續自身提升和代碼質量上都有益。
- 後期制定一個基礎的節點執行流程，過程建模，也就是流程節點控制，好比一個插線板你要用哪個插口你插上，是洗衣機，或是電冰箱就可以用了。
- 事務儘量使用原子事務，不要掛太多的操作，特別是執行比較慢的操作和查詢。For update
- 樂觀鎖：使用比較好，但是在使用時候問題也多，考慮比較多
- 悲觀鎖：事務解決使用原子事務，不好將查詢和執行放一起操作，在數據庫操作做到冪等。
- 不依賴代碼的框架來寫代碼，導致不會關心源代碼的流程和實現，多的時間都學習了框架的使用
用戶交互建模，數據建模
一句話說明，就是和用戶交互的部分和在下層爲用戶訪問提供的數據存儲。中間就是業務平臺來針對也做統一的入和出。
-
對用戶第一交互的部分做交互模型建立。也就是前後端用戶交互的字段和實體有統一的處理。
-
和數據庫交互的建立數據模型，一般都是一個相關的服務會在一個服務中。這個有爭議，比如在service層上提出manager層麼？Service中可以依賴service麼?等等
-
![在這裏插入圖片描述]()
UC設計規範接口
目的是對業務流程有一個總的交互建模。對系統開發有總體的把控
- 從前到後梳理交互模型。是否和業務平臺發生衝突，
- 數據端建立的數據庫是否合理【依賴業務熟悉程度】
- 業務平臺需要梳理提供通用的接口、
- 在網關融合層進行組裝，儘量做跨服務的組裝，在有本地庫和數據的在本地業務平臺處理。
接口文檔統一導出
平臺出口統一
- 對業務處理的統一平臺提供通用接口
- 跨服務查詢相關的操作在融合網關進行組裝。
- 如果是拿着唯一和索引命中的數據直接綁定子表對應的數據。將所有的數據綁定返回，如果遇到性能瓶頸再做單獨的優化處理。
- 不能讓接口氾濫，尤其是提供新的接口和服務聲明時候看看是否是通用接口，如果是需要組長自己來評估。下邊是同樣一個查詢被寫了4次，在優化後一個業務平臺從將近200個接口梳理後剩餘的接口數爲21個左右
![在這裏插入圖片描述]()
日誌打印規範
-
在業務日誌打印使用JSON.toJSONString（obj）時候注意get實現不能拋出異常的情況下使用，這裏的ecCode爲空時候序列化報錯導致業務停滯，所以在有重寫get的地方儘量使用或者不要以get開頭定義方法或者重寫toString
![在這裏插入圖片描述]()
-
在打印業務中的跟蹤時候，使用線程時候在定義線程時候需要使用當前線程包裝後的線程池進行使用。避免多線程的調用不能跟蹤上對應的調用鏈。
原生功能和框架功能共存
- Api聲明儘量不要使用Lombok。
- Validate統一使用hibernateValidate,依賴JSR303的規範