我工作多年，遇到過各種各樣的同事。我見過各種代碼，優秀的、垃圾的、沒有吸引力的等等，所以這篇文章記錄了一個優秀的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。