代碼規範技術分享手稿
阿新 • • 發佈:2019-03-21
系統 實體對象 led sta 原理 屬性 有意 ssm架構 user
1.項目結構混亂 2.代碼不規範,冗余,無從下手 導致 : 功能維護 的難度加大 >> 浪費時間去閱讀源碼 >> 爛代碼裏面繼續寫爛代碼 >> 維護起來越來越困難
看不懂的代碼才是好代碼? 經過設計模式層層封裝的代碼才是好代碼? 簡潔明了,通俗一同,註釋齊全 ==> 好代碼 ! 在註重功能,技術深度和廣度的同時, 我們要懂原理,懂技術, 但是更重要的是寫的一手好代碼. talk is cheap,show me your code !
代碼編寫 =(根據)=>規範=(養成)=> 代碼風格 =(學會)=> 重構 =(培養)=> 代碼設計 =(理解)=> 設計模式
代碼規範的第一步,就是要培養代碼風格
下面我們就從溫州項目,一步步了解代碼規範
為什麽要指定代碼規範?
1.項目結構混亂 2.代碼不規範,冗余,無從下手 導致 : 功能維護 的難度加大 >> 浪費時間去閱讀源碼 >> 爛代碼裏面繼續寫爛代碼 >> 維護起來越來越困難
從技術上的角度來講,你們認為什麽樣的代碼才算好代碼?
看不懂的代碼才是好代碼? 經過設計模式層層封裝的代碼才是好代碼? 簡潔明了,通俗一同,註釋齊全 ==> 好代碼 ! 在註重功能,技術深度和廣度的同時, 我們要懂原理,懂技術, 但是更重要的是寫的一手好代碼. talk is cheap,show me your code !
1.架構
1.1技術
本項目是JavaWeb項目,使用了如下技術- 流行的SSM框架;
- log4j2+slf4j+disruptor 作為異步日誌組件
- druid 連接池
- fastjson和jackson json 工具
- AOP+aspect 控制事務和自定義註解
- swagger 文檔工具
- httpclient 網絡組件
- sigar + JMX 系統監控工具
- apace commons 系列開發工具
- Juint 單元測試
1.2 系統結構
系統結構盡量保持層次分明,結構簡單.用包命名的方式區分業務系統代碼和通用代碼,如下圖所示- commons: 存放通用代碼,比如各種工具類,常量類,日誌組件等.commons下的代碼主要服務於業務代碼
- console: 主要針對web服務,提供訪問接口,如登錄註冊,權限系統等,,但是獨立cell的存在,有自己的一套訪問數據庫和業務邏輯.但是同樣基於SSM架構.
- cell: 提供傳統分層中的Service層和Mapper層.保持最小的基礎邏輯單元,即單表
-
- s001: 業務代碼.負責提供對外訪問業務接口(Controller),業務邏輯(VS)以及值對象(VO).其中以Controller為單位作為服務調用的功能接口.VS註入多個Service提供復雜的業務邏輯,在業務包下,我們指定如下規範:
- 以系統為單位,S開頭加系統編號的形式做頂級業務包命名方式並作為系統編號,如S001;
- 以系統中的模塊為單位,M開頭加模塊編號作為系統包下的模塊包命名並作為模塊編號,如M001;
- 以模塊中的功能為單位,F開頭加功能編號作為為模塊中的具體功能命名作為功能編號,如F001Controller.以系統編號+模塊編號+方法編號,如 /S001/M001/F001;URL前綴為
- save*
- update*
- query*
- view*
- delete*
- 以功能編號命名的VS層,與相同編號的Controller是一對一的關系,只服務此Controller.方法命名方式與URL前綴一致,用來控制事務.
2.開發規範
2.1 命名規範
- 英文命名盡量使用駝峰形式,拼音命名盡量通俗易懂,命名的方法或者屬性盡量有意義,並容易理解
- 反例: int i = updateXXX(TSignInfo record);
- 正例: int signCount = updateTSignInfo (TSignInfo record);
- 系統編號, 模塊編號,功能編號有項目經理提前指定並統一管理
- URL為系統編號+模塊編號+功能編號+save*/update*/query*/view*/delete*
- VS層的方法命名,凡是對數據庫操作的必須以save*/update*/delete*為前綴,方便事務控制
2.2 開發規範
- 類和方法必須寫註釋作為描述說明,接口方法上寫明調用頁面 . 靜態常量要有業務場景或使用說明
- controller層必須進行數據校驗
- 基本數據類型設置默認值. 如 pageSize = 10
- String類型的參數要做判空處理. (推薦使用 apache.commons.lang3.StringUtils)
- json類型的數據做json格式校驗
- controller層數據返回必須按照規範
- 操作數據 使用 ResultModel ,異常使用 ResultModel 返回對應狀態實體對象
- mini ui的分頁查詢 使用MiniList或者規定格式的數據作為返回值 ,異常時返回 {total:0,data:null} 字符串或者MiniList.emptyList();
- 字典表返回List,異常是返回 [] 字符串
- controller層必須進行異常時的數據返回處理
- controller層的每個接口方法必須使用try-catch捕獲異常
- controller層每個接口方法必須做日誌記錄.
- VS層在進行數據庫操作時,必須對操作返回的數值驗證,不正常的返回值進行異常處理 如 update(T t) = 0
- service,dao必須繼承 BaseService, BaseMapper接口,實現規範.生成的基礎邏輯代碼不可修改.有問題聯系項目經理.查詢代碼可自己實現
- 代碼中避免使用魔鬼數字,狀態字段等盡量使用有意義的常量,並且使用常量類統一維護 反例 : obj.setStatus("1");
- 頁面上的 操作請求 必須對返回值狀態 進行判斷 並進行相應的操作 ( 無論是成功還是失敗);
- 精確計算時,必須使用BigDecimal. 避免使用float和double. 浮點運算必須使用BigDecimal或整型運算,如
- 0.5 * 0.01 >> 50*1
代碼規範技術分享手稿