1. 程式人生 > >代碼規範技術分享手稿

代碼規範技術分享手稿

系統 實體對象 led sta 原理 屬性 有意 ssm架構 user

為什麽要指定代碼規範?


1.項目結構混亂 2.代碼不規範,冗余,無從下手 導致 : 功能維護 的難度加大 >> 浪費時間去閱讀源碼 >> 爛代碼裏面繼續寫爛代碼 >> 維護起來越來越困難

從技術上的角度來講,你們認為什麽樣的代碼才算好代碼?


看不懂的代碼才是好代碼? 經過設計模式層層封裝的代碼才是好代碼? 簡潔明了,通俗一同,註釋齊全 ==> 好代碼 ! 在註重功能,技術深度和廣度的同時, 我們要懂原理,懂技術, 但是更重要的是寫的一手好代碼. talk is cheap,show me your code !
代碼編寫 =(根據)=>規範=(養成)=> 代碼風格 =(學會)=> 重構 =(培養)=> 代碼設計 =(理解)=> 設計模式 代碼規範的第一步,就是要培養代碼風格 下面我們就從溫州項目,一步步了解代碼規範

1.架構


1.1技術

本項目是JavaWeb項目,使用了如下技術
  1. 流行的SSM框架;
  2. log4j2+slf4j+disruptor 作為異步日誌組件
  3. druid 連接池
  4. fastjson和jackson json 工具
  5. AOP+aspect 控制事務和自定義註解
  6. swagger 文檔工具
  7. httpclient 網絡組件
  8. sigar + JMX 系統監控工具
  9. apace commons 系列開發工具
  10. Juint 單元測試
技術分享圖片

1.2 系統結構

系統結構盡量保持層次分明,結構簡單.用包命名的方式區分業務系統代碼和通用代碼,如下圖所示 技術分享圖片
  • commons: 存放通用代碼,比如各種工具類,常量類,日誌組件等.commons下的代碼主要服務於業務代碼
  • console: 主要針對web服務,提供訪問接口,如登錄註冊,權限系統等,,但是獨立cell的存在,有自己的一套訪問數據庫和業務邏輯.但是同樣基於SSM架構.
  • cell: 提供傳統分層中的Service層和Mapper層.保持最小的基礎邏輯單元,即單表
    的增刪改查,分頁查詢和列表查詢. 根據業務要求,也可以提供聯表的查詢服務. 聯表查詢時sql寫在主表標註的位置下(如下圖所示).我們建議,在聯表查詢中,盡量少的使用外聯. 此外,在service中,我們不建議一個方法有更新或新增多張表的行為.盡量保持類的單一職責.如果需要多表操作,請在VS層完成.
  • 技術分享圖片

技術分享圖片
  • 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 命名規範

  1. 英文命名盡量使用駝峰形式,拼音命名盡量通俗易懂,命名的方法或者屬性盡量有意義,並容易理解
    1. 反例: int i = updateXXX(TSignInfo record);
    2. 正例: int signCount = updateTSignInfo (TSignInfo record);
  2. 系統編號, 模塊編號,功能編號有項目經理提前指定並統一管理
  3. URL為系統編號+模塊編號+功能編號+save*/update*/query*/view*/delete*
  4. VS層的方法命名,凡是對數據庫操作的必須以save*/update*/delete*為前綴,方便事務控制

2.2 開發規範

  1. 類和方法必須寫註釋作為描述說明,接口方法上寫明調用頁面 . 靜態常量要有業務場景或使用說明
  2. controller層必須進行數據校驗
    1. 基本數據類型設置默認值. 如 pageSize = 10
    2. String類型的參數要做判空處理. (推薦使用 apache.commons.lang3.StringUtils)
    3. json類型的數據做json格式校驗
  3. controller層數據返回必須按照規範
    1. 操作數據 使用 ResultModel ,異常使用 ResultModel 返回對應狀態實體對象
    2. mini ui的分頁查詢 使用MiniList或者規定格式的數據作為返回值 ,異常時返回 {total:0,data:null} 字符串或者MiniList.emptyList();
    3. 字典表返回List,異常是返回 [] 字符串
  4. controller層必須進行異常時的數據返回處理
  5. controller層的每個接口方法必須使用try-catch捕獲異常
  6. controller層每個接口方法必須做日誌記錄.
  7. VS層在進行數據庫操作時,必須對操作返回的數值驗證,不正常的返回值進行異常處理 如 update(T t) = 0
  8. service,dao必須繼承 BaseService, BaseMapper接口,實現規範.生成的基礎邏輯代碼不可修改.有問題聯系項目經理.查詢代碼可自己實現
  9. 代碼中避免使用魔鬼數字,狀態字段等盡量使用有意義的常量,並且使用常量類統一維護 反例 : obj.setStatus("1");
  10. 頁面上的 操作請求 必須對返回值狀態 進行判斷 並進行相應的操作 ( 無論是成功還是失敗);
  11. 精確計算時,必須使用BigDecimal. 避免使用float和double. 浮點運算必須使用BigDecimal或整型運算,如
    1. 0.5 * 0.01 >> 50*1

代碼規範技術分享手稿