Spring 常犯的十大錯誤，這坑你踩過嗎？

閱讀本文大概須要 9 分鐘。

一、錯誤一：太過關注底層

咱們正在解決這個常見錯誤，是由於 「非我所創」 綜合症在軟件開發領域非常常見。症狀包括常常重寫一些常見的代碼，不少開發人員都有這種症狀。

雖然理解特定庫的內部結構及其實現，在很大程度上是好的而且頗有必要的（也能夠是一個很好的學習過程），但做爲軟件工程師，不斷地處理相同的底層實現細節對我的的開發生涯是有害的。

像 Spring 這種抽象框架的存在是有緣由的，它將你從重複地手工勞做中解放出來，並容許你專一於更高層次的細節 —— 領域對象和業務邏輯。

所以，接受抽象。下次面對特定問題時，首先進行快速搜索，肯定解決該問題的庫是否已被集成到 Spring 中；如今，你可能找到一個合適的現成解決方案。

好比，一個頗有用的庫，在本文的其餘部分，我將在示例中使用 Project Lombok 註解。

Lombok 被用做樣板代碼生成器，但願懶惰的開發人員在熟悉這個庫時不會遇到問題。舉個例子，看看使用 Lombok 的 「標準 Java Bean」 是什麼樣子的：

如你所想，上述代碼被編譯爲：

可是，請注意，若是你打算在 IDE 中使用 Lombok，極可能須要安裝一個插件，可在 此處 找到 Intellij IDEA 版本的插件。

二、錯誤二： 內部結構 「泄露」

公開你的內部結構，歷來都不是一個好主意，由於它在服務設計中形成了不靈活性，從而促進了很差的編碼實踐。

「泄露」 的內部機制表現爲使數據庫結構能夠從某些 API 端點訪問。

例如，下面的 POJO（「Plain Old Java Object」）類表示數據庫中的一個表：

假設，存在一個端點，他須要訪問 TopTalentEntity 數據。返回 TopTalentEntity 實例可能很誘人，但更靈活的解決方案是建立一個新的類來表示 API 端點上的 TopTalentEntity 數據。

這樣，對數據庫後端進行更改將不須要在服務層進行任何額外的更改。考慮下，在TopTalentEntity 中添加一個 「password」 字段來存儲數據庫中用戶密碼的 Hash 值 —— 若是沒有 TopTalentData 之類的鏈接器，忘記更改服務前端，將會意外地暴露一些沒必要要的祕密信息。

三、錯誤三： 缺少關注點分離

隨着程序規模的增加，逐漸地，代碼組織成爲一個愈來愈重要的問題。諷刺的是，大多數好的軟件工程原則開始在規模上崩潰 —— 特別是在沒有太多考慮程序體系結構設計的狀況下。

開發人員最常犯的一個錯誤就是混淆代碼關注點，這很容易作到！

一般，打破 關注點分離 的是將新功能簡單地 「倒」 在現有類中。

固然，這是一個很好的短時間解決方案（對於初學者來講，它須要更少的輸入），但它也不可避免地會在未來成爲一個問題，不管是在測試期間、維護期間仍是介於二者之間。

考慮下下面的控制器，它將從數據庫返回 TopTalentData。

起初，這段代碼彷佛沒什麼特別的問題；它提供了一個從 TopTalentEntity 實例檢索出來的TopTalentData 的 List。

然而，仔細觀察下，咱們能夠看到 TopTalentController 實際上在此作了些事情；也就是說，它將請求映射到特定端點，從數據庫檢索數據，並將從 TopTalentRepository 接收的實體轉換爲另外一種格式。

一個「更乾淨」 的解決方案是將這些關注點分離到他們本身的類中。

看起來多是這個樣子的：

這種層次結構的另外一個優勢是，它容許咱們經過檢查類名來肯定將功能駐留在何處。此外，在測試期間，若是須要，咱們能夠很容易地用模擬實現來替換任何類。

四、錯誤四： 缺少異常處理或處理不當

一致性的主題並不是是 Spring（或 Java）所獨有的，但仍然是處理 Spring 項目時須要考慮的一個重要方面。

雖然編碼風格可能存在爭議（一般團隊或整個公司內部已達成一致），但擁有一個共同的標準最終會極大地提升生產力。對多人團隊尤其如此；一致性容許交流發生，而不須要花費不少資源在手把手交接上，也不須要就不一樣類的職責提供冗長的解釋。

考慮一個包含各類配置文件、服務和控制器的 Spring 項目。

在命名時保持語義上的一致性，能夠建立一個易於搜索的結構，任何新的開發人員均可以按照本身的方式管理代碼；例如，將 Config 後綴添加到配置類，服務層以 Service 結尾，以及控制器用 Controller 結尾。

與一致性主題密切相關，服務器端的錯誤處理值得特別強調。

若是你曾經不得不處理編寫不好的 API 的異常響應，那你可能知道緣由 —— 正確解析異常會是一件痛苦的事情，而肯定這些異常最初發生的緣由則更爲痛苦。

做爲一名 API 開發者，理想狀況下你但願覆蓋全部面向用戶的端點，並將他們轉換爲常見的錯誤格式。

這一般意味着有一個通用的錯誤代碼和描述，而不是逃避解決問題：

a) 返回一個 「500 Internal Server Error」信息。

b) 直接返回異常的堆棧信息給用戶。（實際上，這些都應該不惜一切代價地去避免，由於除了客戶端難以處理之外，它還暴露了你的內部信息）。

例如，常見錯誤響應格式可能長這樣：

與此相似的事情在大多數流行的 API 中也常常遇到，因爲能夠容易且系統地記錄，效果每每很不錯。將異常轉換爲這種格式能夠經過向方法提供 @ExceptionHandler 註解來完成（註解案例可見於第六章）。

五、錯誤五： 多線程處理不當

無論是桌面應用仍是 Web 應用，不管是 Spring 仍是 No Spring，多線程都是很難破解的。

由並行執行程序所引發的問題是使人不寒而慄且難以捉摸的，並且經常難以調試 —— 實際上，因爲問題的本質，一旦你意識到你正在處理一個並行執行問題，你可能就不得不徹底放棄調試器了，並 「手動」 檢查代碼，直到找到根本上的錯誤緣由。

不幸的是，這類問題並無千篇一概的解決方案；根據具體場景來評估狀況，而後從你認爲最好的角度來解決問題。

固然，理想狀況下，你也但願徹底避免多線程錯誤。一樣，不存在那種一刀切的方法，但這有一些調試和防止多線程錯誤的實際考慮因素：

(1) 避免全局狀態

首先，牢記 「全局狀態」 問題。若是你正建立一個多線程應用，那麼應該密切關注任何可能全局修改的內容，若是可能的話，將他們所有刪掉。

若是某個全局變量有必須保持可修改的緣由，請仔細使用 synchronization，並對程序性能進行跟蹤，以肯定沒有由於新引入的等待時間而致使系統性能下降。

(2) 避免可變性

這點直接來自於 函數式編程，而且適用於 OOP，聲明應該避免類和狀態的改變。簡而言之，這意味着放棄 setter 方法，並在全部模型類上擁有私有的 final 字段。

它們的值惟一發生變化的時間是在構造期間。

這樣，你能夠肯定不會出現爭用問題，且訪問對象屬性將始終提供正確的值。

(3) 記錄關鍵數據

評估你的程序可能會在何處發生異常，並預先記錄全部關鍵數據。若是發生錯誤，你將很高興能夠獲得信息說明收到了哪些請求，並可更好地瞭解你的應用程序爲何會出現錯誤。

須要再次注意的是，日誌記錄引入了額外的文件 I/O，可能會嚴重影響應用的性能，所以請不要濫用日誌。

(4) 複用現存實現

每當你須要建立本身的線程時（例如：向不一樣的服務發出異步請求），複用現有的安全實現來代替建立本身的解決方案。

這在很大程度上意味着要使用 ExecutorServices 和 Java 8 簡潔的函數式 CompletableFutures 來建立線程。Spring 還容許經過 DeferredResult 類來進行異步請求處理。

六、錯誤六： 不使用基於註解的驗證

假設咱們以前的 TopTalent 服務須要一個端點來添加新的 TopTalent。此外，假設基於某些緣由，每一個新名詞都須要爲 10 個字符長度。

執行此操做的一種方法可能以下：

然而，上面的方法（除了構造不好之外）並非一個真正 「乾淨」 的解決辦法。咱們正檢查不止一種類型的有效性（即 TopTalentData 不得爲空，TopTalentData.name 不得爲空，且 TopTalentData.name 爲 10 個字符長度），以及在數據無效時拋出異常。

經過在 Spring 中集成 Hibernate validator，數據校驗能夠更乾淨地進行。讓咱們首先重構 addTopTalent 方法來支持驗證：

如今，Spring 將在調用方法以前攔截其請求並對參數進行驗證 —— 無需使用額外的手工測試。

另外一種實現相同功能的方法是建立咱們本身的註解。雖然你一般只在須要超出 Hibernate的內置約束集 時才使用自定義註解，本例中，咱們假設 @Length 不存在。

你能夠建立兩個額外的類來驗證字符串長度，一個用於驗證，一個用於對屬性進行註解：

請注意，這些狀況下，關注點分離的最佳實踐要求在屬性爲 null 時，將其標記爲有效（isValid 方法中的 s == null），若是這是屬性的附加要求，則使用 @NotNull 註解。

七、錯誤七： （依舊）使用基於xml的配置

雖然以前版本的 Spring 須要 XML，但現在大部分配置都可經過 Java 代碼或註解來完成；XML 配置只是做爲附加的沒必要要的樣板代碼。

本文（及其附帶的 GitHub 倉庫）均使用註解來配置 Spring，Spring 知道應該鏈接哪些 Bean，由於待掃描的頂級包目錄已在 @SpringBootApplication 複合註解中作了聲明，以下所示：

複合註解（可經過 Spring 文檔 瞭解更多信息）只是向 Spring 提示應該掃描哪些包來檢索 Bean。在咱們的案例中，這意味着這個頂級包 （co.kukurin）將用於檢索：

@Component (TopTalentConverter, MyAnnotationValidator)

@RestController (TopTalentController)

@Repository (TopTalentRepository)

@Service (TopTalentService) 類

若是咱們有任何額外的 @Configuration 註解類，它們也會檢查基於 Java 的配置。

八、錯誤八： 忽略 profile

在服務端開發中，常常遇到的一個問題是區分不一樣的配置類型，一般是生產配置和開發配置。在每次從測試切換到部署應用程序時，不要手動替換各類配置項，更有效的方法是使用 profile。

考慮這麼一種狀況：你正在使用內存數據庫進行本地開發，而在生產環境中使用 MySQL 數據庫。

本質上，這意味着你須要使用不一樣的 URL 和 （但願如此） 不一樣的憑證來訪問這二者。讓咱們看看能夠如何作到這兩個不一樣的配置文件：

(1) APPLICATION.YAML 文件

假設你不但願在修改代碼時意外地對生產數據庫進行任何操做，所以將默認配置文件設爲 dev 是頗有意義的。

而後，在服務器上，你能夠經過提供 -Dspring.profiles.active=prod 參數給 JVM 來手動覆蓋配置文件。

另外，還可將操做系統的環境變量設置爲所需的默認 profile。

九、錯誤九： 沒法接受依賴項注入

正確使用 Spring 的依賴注入意味着容許其經過掃描全部必須的配置類來將全部對象鏈接在一塊兒；這對於解耦關係很是有用，也使測試變得更爲容易，而不是經過類之間的緊耦合來作這樣的事情：

咱們讓 Spring 爲咱們作鏈接：

Misko Hevery 的 Google talk 深刻解釋了依賴注入的 「爲何」，因此，讓咱們看看它在實踐中是如何使用的。

在關注點分離（常見錯誤 #3）一節中，咱們建立了一個服務和控制器類。

假設咱們想在 TopTalentService 行爲正確的前提下測試控制器。咱們能夠經過提供一個單獨的配置類來插入一個模擬對象來代替實際的服務實現：

而後，咱們能夠經過告訴 Spring 使用 SampleUnitTestConfig 做爲它的配置類來注入模擬對象：

以後，咱們就可使用上下文配置將 Bean 注入到單元測試中。

十、錯誤十： 缺少測試，或測試不當

儘管單元測試的概念已經存在很長時間了，但不少開發人員彷佛要麼 「忘記」 作這件事（特別是若是它不是 「必需」 的時候），要麼只是在過後把它添加進來。

這顯然是不可取的，由於測試不只應該驗證代碼的正確性，還應該做爲程序在不一樣場景下應如何表現的文檔。

在測試 Web 服務時，不多隻進行 「純」 單元測試，由於經過 HTTP 進行通訊一般須要調用 Spring 的 DispatcherServlet，並查看當收到一個實際的 HttpServletRequest 時會發生什麼（使它成爲一個 「集成」 測試，處理驗證、序列化等）。

REST Assured，一個用於簡化測試REST服務的 Java DSL，在 MockMVC 之上，已經被證實提供了一個很是優雅的解決方案。

考慮如下帶有依賴項注入的代碼片斷：

SampleUnitTestConfig 類將 TopTalentService 的模擬實現鏈接到 TopTalentController 中，而全部的其餘類都是經過掃描應用類所在包的下級包目錄來推斷出的標準配置。

RestAssuredMockMvc 只是用來設置一個輕量級環境，並向 /toptal/get 端點發送一個 GET請求。

END·

程序員的成長之路

路雖遠，行則必至

本文原發於 同名微信公衆號「程序員的成長之路」，回覆「1024」你懂得，給個讚唄。

回覆 [ 520 ] 領取程序員最佳學習方式

回覆 [ 256 ] 查看 Java 程序員成長規劃