Java後臺開發規範

Java後臺開發規範

1.Java編程規範

1.1.命名風格

• 代碼中的命名均不能以下劃線或美元符號開始，也不能以下劃線或美元符號結束。

• 類名使用 UpperCamelCase 風格，必須遵從駝峯形式，但以下情形例外：DO / BO / DTO / VO / AO

• 接口類中的方法和屬性不要加任何修飾符號，保持代碼的簡潔性，並加上有效的 Javadoc 註釋。儘量不要在接口裏定義變量，如果一定要定義變量，肯定是與接口方法相關，並且是整個應用的基礎常量。

• Service/DAO 層方法命名規約

  • 1） 獲取單個對象的方法用 get 做前綴。
  • 2） 獲取多個對象的方法 list 命名。
  • 3） 獲取統計值的方法用 count 做前綴。
  • 3） 分頁的方法用 page 做後綴。
  • 4） 插入的方法用 save 做前綴。
  • 5） 刪除的方法用 delete 做前綴。
  • 6） 修改的方法用 update 做前綴。

• 領域模型命名規約

  • 1） 數據傳輸對象：xxxDTO，xxx 爲業務領域相關的名稱。
  • 2） 展示對象：xxxVO，xxx 一般爲實體名稱。
  • 3） POJO 是 DO/DTO/BO/VO 的統稱，禁止命名成 xxxPOJO

• 分層領域模型規約

  • DO(Data Object):與數據庫表結構一一對應，通過 DAO 層向上傳輸數據源對象。
  • DTO(Data Transfer Object):數據傳輸對象，Service 或 Manager 向外傳輸的對象。
  • BO(Business Object):業務對象。由 Service 層輸出的封裝業務邏輯的對象。
  • AO(ApplicationObject):應用對象。在Web層與Service層之間抽象的複用對象模型，極爲貼近展示層，複用度不高。
  • VO(View Object):顯示層對象，通常是 Web 向模板渲染引擎層傳輸的對象。
  • Query:數據查詢對象，各層接收上層的查詢請求。注意超過 2 個參數的查詢封裝，禁止使用 Map 類來傳輸。

1.2.代碼格式化規範

每次編輯完一個類後使用idea的格式化功能，格式化代碼和去掉無用導入的包，win快捷鍵爲 Ctrl+Alt+l 和 Ctrl+Alt+o，Mac爲ctrl+option+o 和 option+command+l。

項目的代碼格式統一爲UTF-8。

1.3.API命名規範

GET（SELECT）：從服務器取出資源（一項或多項）。

POST（CREATE）：在服務器新建一個資源。

PUT（UPDATE）：在服務器更新完整的資源（客戶端提供改變後的完整資源）。

DELETE（DELETE）：從服務器刪除資源。

基本規範

• 使用’/'表示層級關係
• url 不能以’/'結尾
• url 中不能包含空格
• url 中不能以文件後綴結尾
• url 中字母小寫，單詞間加下劃線
• 不要再url中添加CRUD

說明	ActionName	HttpMapping	HttpRequestBody	HttpResponseBody
查詢所有	list	GET /v1/user/list?xx=xx	N/A	Resource* list
獲取單個資源	query	GET /v1/user/1	N/A	Resource*
創建單個資源	create	POST /v1/user/create	Resource	Resource*
更新單個資源	update	PUT /v1/user/update	Resource	Resource*
刪除單個資源	delete	DELETE /v1/user/delete	N/	Empty
分頁條件查詢	page	GET /v1/user/page?page=0&size=10	N/A	Resource
批量添加	batchCreate	POST /batch_create	Resource* list	Resource IDS
批量刪除	batchDelete	POST /batch_delete	Resource IDS	Empty
更新用戶的年齡	updateAge	POST /v1/user/1/age?value=20	N/A	{“key”:“age”,“value”:“20”}

1.4.異常處理規範

• 異常不要用來做流程控制，條件控制，因爲異常的處理效率比條件分支低。

• 對大段代碼進行 try-catch，這是不負責任的表現。catch 時請分清穩定代碼和非穩 定代碼，穩定代碼指的是無論如何不會出錯的代碼。對於非穩定代碼的 catch 儘可能進行區分 異常類型，再做對應的異常處理。

• 捕獲異常是爲了處理它，不要捕獲了卻什麼都不處理而拋棄之，如果不想處理它，請 將該異常拋給它的調用者。最外層的業務使用者，必須處理異常，將其轉化爲用戶可以理解的 內容。

• 有 try 塊放到了事務代碼中，catch 異常後，如果需要回滾事務，一定要注意手動回 滾事務。

• finally 塊必須對資源對象、流對象進行關閉，有異常也要做 try-catch。

• 不能在 finally 塊中使用 return，finally 塊中的 return 返回後方法結束執行，不 會再執行 try 塊中的 return 語句。

• 方法的返回值可以爲 null，不強制返回空集合，或者空對象等，必須添加註釋充分 說明什麼情況下會返回 null 值。調用方需要進行 null 判斷防止 NPE 問題。

1.5.模塊化開發規範

模塊化開發是指公司共有的基礎模塊的開發如：短信、權限、支付、公共工具、郵件等。

模塊化開發的pom模版

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.domain.module</groupId>
    <artifactId>domain-module</artifactId>
    <version>1.0.0.RELEASE</version>

    <dependencies>
        <dependency>
            <groupId>org.apache.shiro</groupId>
            <artifactId>shiro-spring</artifactId>
            <version>1.4.0</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.7.0</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <distributionManagement>
        <repository>
            <id>releases</id>
            <name>Nexus release Repository</name>
            <url>http://192.168.0.110:8081/repository/maven-releases/</url>
        </repository>

        <snapshotRepository>
            <id>snapshots</id>
            <name>Nexus snapshots Repository</name>
            <url>http://192.168.0.110:8081/repository/maven-snapshots/</url>
        </snapshotRepository>
    </distributionManagement>

</project>

• 模塊化定義 GAV 遵從以下規則:

  • GroupID格式:com.{域名}.業務線.[子業務線]，最多4級。
  • ArtifactID格式:產品線名-模塊名。語義不重複不遺漏，先到中央倉庫去查證一下。

• 模塊化命名方式:主版本號.次版本號.修訂號

  • 主版本號:產品方向改變，或者大規模API不兼容，或者架構不兼容升級。
  • 次版本號:保持相對兼容性，增加主要功能特性，影響範圍極小的API不兼容修改。 3) 修訂號:保持完全兼容性，修復BUG、新增次要功能特性等。

2.前後端對接規範

• 後端返回格式統一爲json格式數據。

{"code":20000,"message":"success","data":null}

• 後端返回的code字段，以4開頭則爲前端請求有誤，以5開頭則是後端接口問題。2開頭則表示成功。

• 後端返回的message字段表示請求的信息，成功是success，錯誤則會提示相應的異常信息或返回error。

• 後端返回的data字段則是本次請求的數據，無數據則返回null。

• 後端返回的時間格式統一爲時間戳

3.數據庫設計規範

3.1.建表規約

• 表名、字段名必須使用小寫字母或數字，禁止出現數字開頭，禁止兩個下劃線中間只出現數字。數據庫字段名的修改代價很大，因爲無法進行預發佈，所以字段名稱需要慎重考慮。

• 表達是與否概念的字段，必須使用 is_xxx 的方式命名，數據類型是 tinyint (1表示是，0表示否)。

• 表名不使用複數名詞。

• 禁用保留字，如 desc、range、match、delayed 等，請參考 MySQL 官方保留字。

• 主鍵索引名爲 pk_字段名;唯一索引名爲 uk_字段名;普通索引名則爲 idx_字段名。

• 小數類型爲 decimal，禁止使用 float 和 double。

• 如果存儲的字符串長度幾乎相等，使用 char 定長字符串類型。

• varchar 是可變長字符串，不預先分配存儲空間，長度不要超過 5000，如果存儲長 度大於此值，定義字段類型爲 text，獨立出來一張表，用主鍵來對應，避免影響其它字段索 引效率。

• 表必備三字段:id, gmt_create, gmt_modified。

• 表的命名最好是加上"業務名稱_表的作用"。

• 庫名與應用名稱儘量一致。

• 單錶行數超過 500 萬行或者單表容量超過 2GB，才推薦進行分庫分表。

3.2.索引規約

• 業務上具有唯一特性的字段，即使是多個字段的組合，也必須建成唯一索引。

• 超過三個表禁止 join。需要 join 的字段，數據類型必須絕對一致;多表關聯查詢時，保證被關聯的字段需要有索引。

• 在 varchar 字段上建立索引時，必須指定索引長度，沒必要對全字段建立索引，根據實際文本區分度決定索引長度即可。

• 如果有 order by 的場景，請注意利用索引的有序性。order by 最後的字段是組合索引的一部分，並且放在索引組合順序的最後，避免出現 file_sort 的情況，影響查詢性能。

• 利用覆蓋索引來進行查詢操作，避免回表。

• SQL 性能優化的目標:至少要達到 range 級別，要求是 ref 級別，如果可以是 consts 最好。

• 建組合索引的時候，區分度最高的在最左邊。

3.3.SQL 語句

• 不要使用 count(列名)或 count(常量)來替代 count()，count()是 SQL92 定義的 標準統計行數的語法，跟數據庫無關，跟 NULL 和非 NULL 無關。

• count(distinct col) 計算該列除 NULL 之外的不重複行數，注意 count(distinct col1, col2) 如果其中一列全爲NULL，那麼即使另一列有不同的值，也返回爲0。

• 當某一列的值全是 NULL 時，count(col)的返回結果爲 0，但 sum(col)的返回結果爲 NULL，因此使用 sum()時需注意 NPE 問題。

• 使用 ISNULL()來判斷是否爲 NULL 值。

• 在代碼中寫分頁查詢邏輯時，若 count 爲 0 應直接返回，避免執行後面的分頁語句。

• 不得使用外鍵與級聯，一切外鍵概念必須在應用層解決。

• 禁止使用存儲過程，存儲過程難以調試和擴展，更沒有移植性。

• 數據訂正時，刪除和修改記錄時，要先 select，避免出現誤刪除，確認無誤才能執行更新語句。

• in 操作能避免則避免，若實在避免不了，需要仔細評估 in 後邊的集合元素數量，控制在 1000 個之內

• 如果有全球化需要，所有的字符存儲與表示，均以 utf-8 編碼，注意字符統計函數的區別。

• TRUNCATE TABLE 比 DELETE 速度快，且使用的系統和事務日誌資源少，但 TRUNCATE 無事務且不觸發 trigger，有可能造成事故，故不建議在開發代碼中使用此語句。

3.4.ORM 映射

• 在表查詢中，一律不要使用 * 作爲查詢的字段列表，需要哪些字段必須明確寫明。

• POJO 類的布爾屬性不能加 is，而數據庫字段必須加 is_，要求在 resultMap 中進行 字段與屬性之間的映射。

• 不要用 resultClass 當返回參數，即使所有類屬性名與數據庫字段一一對應，也需 要定義;反過來，每一個表也必然有一個與之對應。

• sql.xml 配置參數使用:#{}，#param# 不要使用${} 此種方式容易出現 SQL 注入。

• 不允許直接拿 HashMap 與 Hashtable 作爲查詢結果集的輸出。

• 更新數據表記錄時，必須同時更新記錄對應的 gmt_modified 字段值爲當前時間。

• 不要寫一個大而全的數據更新接口。傳入爲 POJO 類，不管是不是自己的目標更新字 段，都進行 update table set c1=value1,c2=value2,c3=value3; 這是不對的。執行 SQL 時，不要更新無改動的字段，一是易出錯;二是效率低;三是增加 binlog 存儲。

• @Transactional 事務不要濫用。事務會影響數據庫的 QPS，另外使用事務的地方需 要考慮各方面的回滾方案，包括緩存回滾、搜索引擎回滾、消息補償、統計修正等。

4.服務部署規範

• 在線上生產環境，JVM的Xms和Xmx設置一樣大小的內存容量，避免在GC 後調整堆 大小帶來的壓力。

• 給 JVM 設置-XX:+HeapDumpOnOutOfMemoryError 參數，讓 JVM 碰到 OOM 場景時輸出 dump 信息。

參考：阿里巴巴Java開發手冊