幾個友好Java程式碼習慣建議

語言: CN / TW / HK

我工作多年,遇到過各種各樣的同事。我見過各種程式碼,優秀的、垃圾的、沒有吸引力的等等,所以這篇文章記錄了一個優秀的Java開發應該具備哪些良好的開發習慣或最佳實踐。

1、封裝方法引數

當你的方法引數過多時,建議封裝一個物件。下面是反面教材,誰教你寫成這樣的程式碼?

public void updateX(long num, String str1, String str2,                     String str3, String str4,                    String str5, String str6) {}

儘量把這些輸出封裝到一個物件中。

public class X {    private Long num;    private String str1;    ...}

為什麼要這樣寫?例如,您的方法用於查詢。如果以後新增查詢條件,需要修改方法嗎?每次新增時必須更改方法引數列表。封裝一個物件,以後無論新增多少查詢條件,只需要給物件新增欄位即可。關鍵是程式碼看起來也很舒服!

2、封裝業務邏輯

如果你看過“狗屎山”,你會有很深的感受。這樣的方法可以寫幾千行程式碼,沒有什麼規則可言。經常負責人會說,這個業務太複雜了,沒辦法改進,是偷懶的藉口。無論業務多麼複雜,我們都可以通過合理的設計和封裝來提高程式碼的可讀性。下面是一個建議的程式碼。

@Transactionalpublic void clearBills(Long customerId) {    //獲取清算所需的票據ng    ClearContext context = getClearContext(customerId);    // 驗證該金額是否合法    checkAmount(context);    // 確定優惠券是否可用,並返回可扣除金額    CouponDeductibleResponse deductibleResponse = couponDeducted(context);    // 結清所有賬單    DepositClearResponse response = clearBills(context);    // 傳送還款對賬訊息    repaymentService.sendVerifyBillMessage(customerId, context.getDeposit());    // 更新帳戶餘額    accountService.clear(context, response);    // 處理已清算的息票,用完或未繫結    couponService.clear(deductibleResponse);    // 儲存優惠券扣減記錄    clearCouponDeductService.add(context, deductibleResponse);}

這段程式碼中的業務非常複雜。估計內部保守做了一萬件事情,但是不同層次的人寫的東西完全不一樣。不得不讚這個業務的拆分,方法的封裝。大企業中有多個小企業。不同的業務可以呼叫不同的服務方法。

接手的人即使沒有流程圖等相關檔案,也能快速瞭解業務。初級開發寫的很多業務方法都是上一行程式碼給業務A,下一行程式碼給業務B,下一行程式碼給業務A。還有一堆單元邏輯巢狀在業務之間呼叫,這非常混亂並且有很多程式碼。

3、判斷集合型別不為空的正確方法

很多人喜歡寫這樣的程式碼來判斷集合。

if (list == null || list.size() == 0) {  return null;}

當然,如果你堅持這樣寫是沒有問題的。

org.springframework.util.CollectionUtils但是你不覺得不舒服嗎,現在框架中的任何一個jar包都有一個收集工具類,比如com.baomidou.mybatisplus.core.toolkit.CollectionUtils. 以後請這樣寫。

if (CollectionUtils.isEmpty(list)) {  return null;}

4、集合型別返回值不返回null

當你的業務方法返回一個集合型別時,請不要返回null,正確的操作是返回一個空集合。看一下mybatis的列表查詢。如果沒有查詢任何元素,它將返回一個空集合而不是 null。否則,呼叫者必須做NULL判斷,大多數情況下物件也是如此。

5、推薦使用lombok

當然,這是一個有爭議的問題,我的習慣是使用它來省略 getter、setter、toString 等。使用Lombok。

6、編寫儘可能少的工具

為什麼要少寫一些工具類,因為你寫的大部分工具類都包含在你引入的jar包中,比如String、Assert斷言、IO上傳檔案、複製流、Bigdecimal]等等。編寫自己的錯誤並載入冗餘類很容易。

7、寫有意義的方法註釋

寫這種註釋是不是怕後來接手的人瞎了。

要麼不要寫它,要麼只是在它之後新增一個描述。寫這樣的註釋並從IDEA收到一堆警告很痛苦。

/*** 請求號碼驗證** @param a* @param b* @param param* @return Result*/

8、儘量不要讓IDEA報警

很反感在IDEA程式碼視窗看到一連串的警告,很不舒服。因為有警告,說明程式碼可以優化,或者有問題。幾天前,我在團隊中發現了一個小錯誤。和我沒有關係,只是同事們在外面看業務,判斷業務為什麼錯了。我掃了一眼問題。

因為java中的整型字面量int是型別的,所以它們變成Integer了集合,然後點選它stepId就是一個long型別,而Long在集合中,那麼這contains正確返回false了,它不是一個型別。

你看,如果你注意警告,你可以把滑鼠移到上面看一下提示,就會少一個生產bug。

9、儘可能使用新的技術元件

我認為這是一個程式設計師應該具備的素質。反正我喜歡用新的技術部件,因為新技術元件的出現是解決老技術元件的不足,而作為技術人員,我們應該與時俱進。

當然,前提是做好準備,而不是想當然地升級。Java 17 已經發布了最簡單的例子,新專案仍然使用Date來處理 DateTime。