本文翻譯自國外論壇 medium，原文地址：https://medium.com/@raviyasas/spring-boot-best-practices-for-developers-3f3bdffa0090

Spring Boot 是一種廣泛使用且非常流行的企業級高性能框架。以下是一些最佳實踐和一些技巧，我們可以使用它們來改進 Spring Boot 應用程式並使其更加高效。這篇文章會有點長，完整讀完文章需要一些時間。

1.正確的包目錄風格

• 正確的包目錄將有助於輕鬆理解代碼和應用程式的流程。
• 我們可以使用有意義的包目錄來構建我們的應用程式。
• 我們可以將所有控制器包含在單獨的包中，將服務包含在單獨的包中，將 util 類包含在單獨的包中等等。這種風格在小型微服務中非常方便。
• 如果我們正在處理龐大的代碼庫，則可以使用基於功能模塊的方法。我們可以根據我們的要求來決定。

基於類型

基於功能模塊

推薦博主開源的 H5 商城項目waynboot-mall，這是一套全部開源的微商城項目，包含三個項目：運營後臺、H5 商城前臺和服務端介面。實現了商城所需的首頁展示、商品分類、商品詳情、商品 sku、分詞搜索、購物車、結算下單、支付寶/微信支付、收單評論以及完善的後臺管理等一系列功能。 技術上基於最新得 Springboot3.0、jdk17，整合了 MySql、Redis、RabbitMQ、ElasticSearch 等常用中間件。分模塊設計、簡潔易維護，歡迎大家點個 star、關註博主。

github 地址：https://github.com/wayn111/waynboot-mall

2.使用設計模式

沒什麼好說的，設計模式已經是現代編程中編寫可維護、可擴展代碼的最佳實踐。

3.使用 Spring Boot starter

• 這是 Spring Boot 的一個很酷的功能。
• 我們可以非常輕鬆地使用啟動器依賴項，而無需一一添加單個依賴項。這些入門依賴項已與所需的依賴項捆綁在一起。
• 例如，如果我們添加 spring-boot-starter-web 依賴項，預設情況下它會與 jackson、spring-core、spring-mvc 和 spring-boot-starter-tomcat 依賴項捆綁在一起。
• 所以我們不需要關心單獨添加依賴項。
• 它還可以幫助我們避免版本不匹配。

4.使用生產版本的依賴項

• 始終建議使用最新的穩定 GA 版本。
• 有時它可能會因 Java 版本、伺服器版本、應用程式類型等而有所不同。
• 不要使用同一包的不同版本，如果存在多個依賴項，請始終使用 <properties> 指定版本。

5.使用 Lombok

• 作為一名 Java 開發人員，我們可能聽說過 Lombok 項目。
• Lombok 是一個 Java 庫，可用於減少代碼並允許我們使用其註釋編寫乾凈的代碼。
• 例如，我們可能在某些類（如實體、請求/響應對象、dtos 等）中使用大量的 getter 和 setter 行。
• 但如果你使用 Lombok，它只是一行，你可以根據你的要求使用@Data、@Getter 或@Setter。
• 我們也可以使用 Lombok 記錄器註釋。推薦@Slf4j。

6.將構造函數註入與 Lombok 一起使用

• 當我們談論依賴註入時，有兩種類型。
• 一種是“構造函數註入”，另一種是“setter 註入”。除此之外，我們還可以使用非常流行的@Autowired 註釋來使用“欄位註入”。
• 但我們強烈建議使用構造函數註入而不是其他類型。因為它允許應用程式在初始化時初始化所有必需的依賴項。
• 這對於單元測試非常有用。
• 重要的是，我們可以使用 Lombok 的 @RequiredArgsConstructor 註釋來使用構造函數註入。

7.使用 slf4j 日誌

• 日誌記錄非常重要。
• 如果我們的應用程式在生產過程中出現問題，日誌記錄是找出根本原因的唯一方法。
• 因此，在添加記錄器、日誌消息類型、記錄器級別和記錄器消息之前應該仔細考慮。
• 不要使用 System.out.print()
• 建議將 Slf4j 與 Spring Boot 中預設的日誌框架 logback 一起使用。
• 始終使用 slf4j 的 {} 占位符語法，避免在記錄器消息中使用字元串插值。因為字元串插值會消耗更多的記憶體。
• 我們可以使用 Lombok @Slf4j 註釋非常輕鬆地創建日誌記錄器。
• 如果我們處於微服務環境中，則可以使用 ELK 技術棧。

8.控制器僅用於路由

• 控制器專用於路由。
• 它是無狀態且單身的。
• DispatcherServlet 將檢查控制器上的 @RequestMapping
• 控制器是請求的最終目標，請求將交給服務層並由服務層處理。
• 業務邏輯不應位於控制器中。

9.使用 Service 層來實現業務邏輯

• 完整的 Service 層業務邏輯包含驗證、緩存等。
• Service 服務與持久層通信並接收結果。
• Service 服務也是單例的。

10.避免空指針異常

• 為了避免 NullPointerException，我們可以使用 java.util 包中的 Optional。
• 我們還可以使用空安全庫。例如：Apache Commons StringUtils
• 對已知對象調用 equals() 和 equalsIgnoreCase() 方法。
• 使用 valueOf() 而不是 toString()
• 使用基於 IDE 的 @NotNull 和 @Nullable 註釋。

11.使用集合框架的最佳實踐

• 對我們的數據集使用適當的集合。
• 將 forEach 與 Java 8 功能結合使用，並避免使用舊版 for 迴圈。
• 使用介面類型而不是實現。
• 使用 isEmpty() 而不是 size() 以獲得更好的可讀性。
• 不返回空值，可以返回空集合。
• 如果我們使用對象作為要存儲在基於哈希的集合中的數據，則應重寫 equals() 和 hashCode() 方法。

12.使用分頁

• 這將提高應用程式的性能。
• 如果我們使用 Spring Data JPA，則 PagingAndSortingRepository 使分頁的使用變得非常容易且幾乎不費吹灰之力。

13.使用緩存

• 在談論應用程式性能時，緩存是另一個重要因素。
• 預設情況下，Spring Boot 通過 ConcurrentHashMap 提供緩存，我們可以通過 @EnableCaching 註解來實現這一點。
• 如果我們對預設緩存不滿意，可以使用 Redis、Hazelcast 或任何其他分散式緩存實現。
• Redis 和 Hazelcast 是記憶體緩存方法。我們還可以使用資料庫緩存實現。

14.使用自定義異常處理程式和全局異常處理

• 這在使用大型企業級應用程式時非常重要。
• 除了一般異常之外，我們可能還會有一些場景來識別某些特定的錯誤情況。
• 異常顧問可以使用 @ControllerAdvice 創建，我們可以創建具有有意義細節的單獨異常。
• 它將使得將來識別和調試錯誤變得更加容易。

15.使用自定義響應對象

• 自定義響應對象可用於返回包含某些特定數據的對象，並滿足 HTTP 狀態代碼、API 代碼、消息等要求。
• 我們可以使用構建器設計模式來創建具有自定義屬性的自定義響應對象。

16.刪除不必要的代碼、變數、方法和類。

• 未使用的變數聲明將占用一些記憶體。
• 刪除未使用的方法、類等，因為它會影響應用程式的性能。
• 儘量避免嵌套迴圈，我們可以使用 map 代替。

17.使用註釋

• 註釋是一個很好的做法。
• 不要對一切代碼發表註釋。相反，我們可以使用類、函數、方法、變數等有意義的單詞編寫描述性代碼。
• 刪除註釋代碼、誤導性註釋和故事型註釋。
• 我們可以使用註釋進行警告，並解釋一些乍一看難以理解的內容。

18.對類、方法、函數、變數和其他屬性使用有意義的詞語。

• 這看起來很簡單，但影響卻是巨大的。
• 始終使用正確的有意義且可搜索的命名約定以及正確的大小寫。
• 通常，我們在聲明類、變數和常量時使用名詞或短語。例如：字元串 firstName，const isValid
• 我們可以使用帶有形容詞的動詞和短語來表示函數和方法。例如：readFile()、sendData()
• 避免使用縮寫變數名和意圖揭示的名稱。例如： int i;字元串 getExUsr;
• 如果我們有意義地使用此功能，則可以減少聲明註釋行。由於它具有有意義的名稱，新開發人員可以通過閱讀代碼輕鬆理解。

19.使用正確的大小寫進行聲明

• 有許多不同的大小寫，如大寫、小寫、駝峰命名、帕斯卡命名、蛇命名、大蛇式命名、短橫線命名等。

• 但我們需要確定哪個案例專用於哪個變數。

• 通常我會遵循如下方式，

  類 — 帕斯卡命名

  方法和變數 — 駝峰命名

  常量 — 大蛇式命名

  資料庫相關欄位 — 短橫線命名

  這隻是一個例子,它可能與我們在公司遵循的標準不同。

20.簡單點

• 始終嘗試編寫簡單、可讀的代碼。
• 同樣簡單的邏輯可以用不同的方式實現，但是如果不可讀或不理解就很難理解。
• 有時複雜的邏輯會消耗更多的記憶體。
• 編寫代碼時嘗試使用 KISS、DRY 和 SOLID 原則。我將在以後的文章中解釋這一點。

21.使用通用的代碼格式樣式

• 格式樣式因開發人員而異。編碼風格的改變也被認為是一種改變，並且會使代碼合併變得非常困難。
• 為了避免這種情況，團隊可以採用通用的編碼格式。

22.使用 SonarLint 插件

• 這對於識別小錯誤和最佳實踐非常有用，以避免不必要的錯誤和代碼質量問題。
• 我們可以將插件安裝到我們最喜歡的 IDE 中。

最後

至此本文講解內容到此完畢感謝閱讀，希望本文能對你有所幫助。

關註公眾號【waynblog】每周分享技術乾貨、開源項目、實戰經驗、高效開發工具等，您的關註將是我的更新動力！