Spring 可以說是最流行的 Java 框架之一，也是一隻需要馴服的強大野獸。雖然它的基本概念相當容易掌握，但成為一名強大的 Spring 開發者仍需要很多時間和努力。
在本文中，我們將介紹 Spring 中一些常見的錯誤，特別是面向 Web 應用程式和 Spring Boot。正如 Spring Boot 官網 所說，Spring Boot 對應該如何構建 Production-Ready 的應用保持著 相當固執的觀點，本文將嘗試模仿這種觀點，並提供一些技巧的概述，這些技巧將很好地融入標準 Spring Boot 的 web 應用程式開發中去。
如果你對 Spring Boot 還不是很熟悉，但仍想嘗試下接下來提到的一些內容，我也為本文建立了一個 GitHub 倉庫。如果你在閱讀過程中感到困惑，我建議把程式碼 clone 下來，並在本地電腦上使用這些程式碼。
1. 常見錯誤一：太過關注底層
我們正在解決這個常見錯誤，是因為 “非我所創” 綜合症在軟體開發領域很是常見。症狀包括經常重寫一些常見的程式碼，很多開發人員都有這種症狀。
雖然理解特定庫的內部結構及其實現，在很大程度上是好的並且很有必要的（也可以是一個很好的學習過程），但作為軟體工程師，不斷地處理相同的底層實現細節對個人的開發生涯是有害的。像 Spring 這種抽象框架的存在是有原因的，它將你從重複地手工勞作中解放出來，並允許你專注於更高層次的細節 —— 領域物件和業務邏輯。
因此，接受抽象。下次面對特定問題時，首先進行快速搜尋，確定解決該問題的庫是否已被整合到 Spring 中；現在，你可能找到一個合適的現成解決方案。比如，一個很有用的庫，在本文的其他部分，我將在示例中使用 Project Lombok 註解。Lombok 被用作樣板程式碼生成器，希望懶惰的開發人員在熟悉這個庫時不會遇到問題。舉個例子，看看使用 Lombok 的 “標準 Java Bean” 是什麼樣子的：
@Getter
@Setter
@NoArgsConstructor
public class Bean implements Serializable {
int firstBeanProperty;
String secondBeanProperty;
}如你所想，上述程式碼被編譯為：
public class Bean implements Serializable {
private int firstBeanProperty;
private String secondBeanProperty;
public int getFirstBeanProperty() {
return this.firstBeanProperty;
}
public String getSecondBeanProperty() {
return this.secondBeanProperty;
}
public void setFirstBeanProperty(int firstBeanProperty) {
this.firstBeanProperty = firstBeanProperty;
}
public void setSecondBeanProperty(String secondBeanProperty) {
this.secondBeanProperty = secondBeanProperty;
}
public Bean() {
}
}但是，請注意，如果你打算在 IDE 中使用 Lombok，很可能需要安裝一個外掛，可在 此處 找到 Intellij IDEA 版本的外掛。
2. 常見錯誤二：內部結構 “洩露”
公開你的內部結構，從來都不是一個好主意，因為它在服務設計中造成了不靈活性，從而促進了不好的編碼實踐。“洩露” 的內部機制表現為使資料庫結構可以從某些 API 端點訪問。例如，下面的 POJO（“Plain Old Java Object”）類表示資料庫中的一個表：
@Entity
@NoArgsConstructor
@Getter
public class TopTalentEntity {
@Id
@GeneratedValue
private Integer id;
@Column
private String name;
public TopTalentEntity(String name) {
this.name = name;
}
}假設，存在一個端點，他需要訪問 TopTalentEntity 資料。返回 TopTalentEntity 例項可能很誘人，但更靈活的解決方案是建立一個新的類來表示 API 端點上的 TopTalentEntity 資料。
@AllArgsConstructor
@NoArgsConstructor
@Getter
public class TopTalentData {
private String name;
}這樣，對資料庫後端進行更改將不需要在服務層進行任何額外的更改。考慮下，在 TopTalentEntity 中新增一個 “password” 欄位來儲存資料庫中使用者密碼的 Hash 值 —— 如果沒有 TopTalentData 之類的聯結器，忘記更改服務前端，將會意外地暴露一些不必要的祕密資訊。
3. 常見錯誤三：缺乏關注點分離
隨著程式規模的增長，逐漸地，程式碼組織成為一個越來越重要的問題。諷刺的是，大多數好的軟體工程原則開始在規模上崩潰 —— 特別是在沒有太多考慮程式體系結構設計的情況下。開發人員最常犯的一個錯誤就是混淆程式碼關注點，這很容易做到！
通常，打破 關注點分離 的是將新功能簡單地 “倒” 在現有類中。當然，這是一個很好的短期解決方案（對於初學者來說，它需要更少的輸入），但它也不可避免地會在將來成為一個問題，無論是在測試期間、維護期間還是介於兩者之間。考慮下下面的控制器，它將從資料庫返回 TopTalentData。
@RestController
public class TopTalentController {
private final TopTalentRepository topTalentRepository;
@RequestMapping("/toptal/get")
public List<TopTalentData> getTopTalent() {
return topTalentRepository.findAll()
.stream()
.map(this::entityToData)
.collect(Collectors.toList());
}
private TopTalentData entityToData(TopTalentEntity topTalentEntity) {
return new TopTalentData(topTalentEntity.getName());
}
}起初，這段程式碼似乎沒什麼特別的問題；它提供了一個從 TopTalentEntity 例項檢索出來的 TopTalentData 的 List。然而，仔細觀察下，我們可以看到 TopTalentController 實際上在此做了些事情；也就是說，它將請求對映到特定端點，從資料庫檢索資料，並將從 TopTalentRepository 接收的實體轉換為另一種格式。一個“更乾淨” 的解決方案是將這些關注點分離到他們自己的類中。看起來可能是這個樣子的：
@RestController
@RequestMapping("/toptal")
@AllArgsConstructor
public class TopTalentController {
private final TopTalentService topTalentService;
@RequestMapping("/get")
public List<TopTalentData> getTopTalent() {
return topTalentService.getTopTalent();
}
}
@AllArgsConstructor
@Service
public class TopTalentService {
private final TopTalentRepository topTalentRepository;
private final TopTalentEntityConverter topTalentEntityConverter;
public List<TopTalentData> getTopTalent() {
return topTalentRepository.findAll()
.stream()
.map(topTalentEntityConverter::toResponse)
.collect(Collectors.toList());
}
}
@Component
public class TopTalentEntityConverter {
public TopTalentData toResponse(TopTalentEntity topTalentEntity) {
return new TopTalentData(topTalentEntity.getName());
}
}這種層次結構的另一個優點是，它允許我們通過檢查類名來確定將功能駐留在何處。此外，在測試期間，如果需要，我們可以很容易地用模擬實現來替換任何類。
4. 常見錯誤四：缺乏異常處理或處理不當
一致性的主題並非是 Spring（或 Java）所獨有的，但仍然是處理 Spring 專案時需要考慮的一個重要方面。雖然編碼風格可能存在爭議（通常團隊或整個公司內部已達成一致），但擁有一個共同的標準最終會極大地提高生產力。對多人團隊尤為如此；一致性允許交流發生，而不需要花費很多資源在手把手交接上，也不需要就不同類的職責提供冗長的解釋。
考慮一個包含各種配置檔案、服務和控制器的 Spring 專案。在命名時保持語義上的一致性，可以建立一個易於搜尋的結構，任何新的開發人員都可以按照自己的方式管理程式碼；例如，將 Config 字尾新增到配置類，服務層以 Service 結尾，以及控制器用 Controller 結尾。
與一致性主題密切相關，伺服器端的錯誤處理值得特別強調。如果你曾經不得不處理編寫很差的 API 的異常響應，那你可能知道原因 —— 正確解析異常會是一件痛苦的事情，而確定這些異常最初發生的原因則更為痛苦。
作為一名 API 開發者，理想情況下你希望覆蓋所有面向使用者的端點，並將他們轉換為常見的錯誤格式。這通常意味著有一個通用的錯誤程式碼和描述，而不是逃避解決問題：a) 返回一個 “500 Internal Server Error”資訊。b) 直接返回異常的堆疊資訊給使用者。（實際上，這些都應該不惜一切代價地去避免，因為除了客戶端難以處理以外，它還暴露了你的內部資訊）。
例如，常見錯誤響應格式可能長這樣：
@Value
public class ErrorResponse {
private Integer errorCode;
private String errorMessage;
}與此類似的事情在大多數流行的 API 中也經常遇到，由於可以容易且系統地記錄，效果往往很不錯。將異常轉換為這種格式可以通過向方法提供 @ExceptionHandler 註解來完成（註解案例可見於第六章）。
5. 常見錯誤五：多執行緒處理不當
不管是桌面應用還是 Web 應用，無論是 Spring 還是 No Spring，多執行緒都是很難破解的。由並行執行程式所引起的問題是令人毛骨悚然且難以捉摸的，而且常常難以除錯 —— 實際上，由於問題的本質，一旦你意識到你正在處理一個並行執行問題，你可能就不得不完全放棄偵錯程式了，並 “手動” 檢查程式碼，直到找到根本上的錯誤原因。不幸的是，這類問題並沒有千篇一律的解決方案；根據具體場景來評估情況，然後從你認為最好的角度來解決問題。
當然，理想情況下，你也希望完全避免多執行緒錯誤。同樣，不存在那種一刀切的方法，但這有一些除錯和防止多執行緒錯誤的實際考慮因素：
5.1. 避免全域性狀態
首先，牢記 “全域性狀態” 問題。如果你正建立一個多執行緒應用，那麼應該密切關注任何可能全域性修改的內容，如果可能的話，將他們全部刪掉。如果某個全域性變數有必須保持可修改的原因，請仔細使用 synchronization，並對程式效能進行跟蹤，以確定沒有因為新引入的等待時間而導致系統效能降低。
5.2. 避免可變性
這點直接來自於 函數語言程式設計，並且適用於 OOP，宣告應該避免類和狀態的改變。簡而言之，這意味著放棄 setter 方法，並在所有模型類上擁有私有的 final 欄位。它們的值唯一發生變化的時間是在構造期間。這樣，你可以確定不會出現爭用問題，且訪問物件屬性將始終提供正確的值。
5.3. 記錄關鍵資料
評估你的程式可能會在何處發生異常，並預先記錄所有關鍵資料。如果發生錯誤，你將很高興可以得到資訊說明收到了哪些請求，並可更好地瞭解你的應用程式為什麼會出現錯誤。需要再次注意的是，日誌記錄引入了額外的檔案 I/O，可能會嚴重影響應用的效能，因此請不要濫用日誌。
5.4. 複用現存實現
每當你需要建立自己的執行緒時（例如：向不同的服務發出非同步請求），複用現有的安全實現來代替建立自己的解決方案。這在很大程度上意味著要使用 ExecutorServices 和 Java 8 簡潔的函式式 CompletableFutures 來建立執行緒。Spring 還允許通過 DeferredResult 類來進行非同步請求處理。
6. 常見錯誤六：不使用基於註解的驗證
假設我們之前的 TopTalent 服務需要一個端點來新增新的 TopTalent。此外，假設基於某些原因，每個新名詞都需要為 10 個字元長度。執行此操作的一種方法可能如下：
@RequestMapping("/put")
public void addTopTalent(@RequestBody TopTalentData topTalentData) {
boolean nameNonExistentOrHasInvalidLength =
Optional.ofNullable(topTalentData)
.map(TopTalentData::getName)
.map(name -> name.length() == 10)
.orElse(true);
if (nameNonExistentOrInvalidLength) {
// throw some exception
}
topTalentService.addTopTalent(topTalentData);
}然而，上面的方法（除了構造很差以外）並不是一個真正 “乾淨” 的解決辦法。我們正檢查不止一種型別的有效性（即 TopTalentData 不得為空，TopTalentData.name 不得為空，且 TopTalentData.name 為 10 個字元長度），以及在資料無效時丟擲異常。
通過在 Spring 中整合 Hibernate validator，資料校驗可以更乾淨地進行。讓我們首先重構 addTopTalent 方法來支援驗證：
@RequestMapping("/put")
public void addTopTalent(@Valid @NotNull @RequestBody TopTalentData topTalentData) {
topTalentService.addTopTalent(topTalentData);
}
@ExceptionHandler
@ResponseStatus(HttpStatus.BAD_REQUEST)
public ErrorResponse handleInvalidTopTalentDataException(MethodArgumentNotValidException methodArgumentNotValidException) {
// handle validation exception
}此外，我們還必須指出我們想要在 TopTalentData 類中驗證什麼屬性：
public class TopTalentData {
@Length(min = 10, max = 10)
@NotNull
private String name;
}現在，Spring 將在呼叫方法之前攔截其請求並對引數進行驗證 —— 無需使用額外的手工測試。
另一種實現相同功能的方法是建立我們自己的註解。雖然你通常只在需要超出 Hibernate的內建約束集 時才使用自定義註解，本例中，我們假設 @Length 不存在。你可以建立兩個額外的類來驗證字串長度，一個用於驗證，一個用於對屬性進行註解：
@Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Constraint(validatedBy = { MyAnnotationValidator.class })
public @interface MyAnnotation {
String message() default "String length does not match expected";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
int value();
}
@Component
public class MyAnnotationValidator implements ConstraintValidator<MyAnnotation, String> {
private int expectedLength;
@Override
public void initialize(MyAnnotation myAnnotation) {
this.expectedLength = myAnnotation.value();
}
@Override
public boolean isValid(String s, ConstraintValidatorContext constraintValidatorContext) {
return s == null || s.length() == this.expectedLength;
}
}請注意，這些情況下，關注點分離的最佳實踐要求在屬性為 null 時，將其標記為有效（isValid 方法中的 s == null），如果這是屬性的附加要求，則使用 @NotNull 註解。
public class TopTalentData {
@MyAnnotation(value = 10)
@NotNull
private String name;
}7. 常見錯誤七：（依舊）使用基於xml的配置
雖然之前版本的 Spring 需要 XML，但如今大部分配置均可通過 Java 程式碼或註解來完成；XML 配置只是作為附加的不必要的樣板程式碼。
本文（及其附帶的 GitHub 倉庫）均使用註解來配置 Spring，Spring 知道應該連線哪些 Bean，因為待掃描的頂級包目錄已在 @SpringBootApplication 複合註解中做了宣告，如下所示：
@SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}複合註解（可通過 Spring 文件 瞭解更多資訊）只是向 Spring 提示應該掃描哪些包來檢索 Bean。在我們的案例中，這意味著這個頂級包 （co.kukurin）將用於檢索：
@Component(TopTalentConverter,MyAnnotationValidator)@RestController(TopTalentController)@Repository(TopTalentRepository)@Service(TopTalentService) 類
如果我們有任何額外的 @Configuration 註解類，它們也會檢查基於 Java 的配置。
8. 常見錯誤八：忽略 profile
在服務端開發中，經常遇到的一個問題是區分不同的配置型別，通常是生產配置和開發配置。在每次從測試切換到部署應用程式時，不要手動替換各種配置項，更有效的方法是使用 profile。
考慮這麼一種情況：你正在使用記憶體資料庫進行本地開發，而在生產環境中使用 MySQL 資料庫。本質上，這意味著你需要使用不同的 URL 和 （希望如此） 不同的憑證來訪問這兩者。讓我們看看可以如何做到這兩個不同的配置檔案：
8.1. APPLICATION.YAML 檔案
# set default profile to 'dev'
spring.profiles.active: dev
# production database details
spring.datasource.url: 'jdbc:mysql://localhost:3306/toptal'
spring.datasource.username: root
spring.datasource.password:8.2. APPLICATION-DEV.YAML 檔案
spring.datasource.url: 'jdbc:h2:mem:'
spring.datasource.platform: h2假設你不希望在修改程式碼時意外地對生產資料庫進行任何操作，因此將預設配置檔案設為 dev 是很有意義的。然後，在伺服器上，你可以通過提供 -Dspring.profiles.active=prod 引數給 JVM 來手動覆蓋配置檔案。另外，還可將作業系統的環境變數設定為所需的預設 profile。
9. 常見錯誤九：無法接受依賴項注入
正確使用 Spring 的依賴注入意味著允許其通過掃描所有必須的配置類來將所有物件連線在一起；這對於解耦關係非常有用，也使測試變得更為容易，而不是通過類之間的緊耦合來做這樣的事情：
public class TopTalentController {
private final TopTalentService topTalentService;
public TopTalentController() {
this.topTalentService = new TopTalentService();
}
}我們讓 Spring 為我們做連線：
public class TopTalentController {
private final TopTalentService topTalentService;
public TopTalentController(TopTalentService topTalentService) {
this.topTalentService = topTalentService;
}
}Misko Hevery 的 Google talk 深入解釋了依賴注入的 “為什麼”，所以，讓我們看看它在實踐中是如何使用的。在關注點分離（常見錯誤 #3）一節中，我們建立了一個服務和控制器類。假設我們想在 TopTalentService 行為正確的前提下測試控制器。我們可以通過提供一個單獨的配置類來插入一個模擬物件來代替實際的服務實現：
@Configuration
public class SampleUnitTestConfig {
@Bean
public TopTalentService topTalentService() {
TopTalentService topTalentService = Mockito.mock(TopTalentService.class);
Mockito.when(topTalentService.getTopTalent()).thenReturn(
Stream.of("Mary", "Joel").map(TopTalentData::new).collect(Collectors.toList()));
return topTalentService;
}
}然後，我們可以通過告訴 Spring 使用 SampleUnitTestConfig 作為它的配置類來注入模擬物件：
@ContextConfiguration(classes = { SampleUnitTestConfig.class })之後，我們就可以使用上下文配置將 Bean 注入到單元測試中。
10. 常見錯誤十：缺乏測試，或測試不當
儘管單元測試的概念已經存在很長時間了，但很多開發人員似乎要麼 “忘記” 做這件事（特別是如果它不是 “必需” 的時候），要麼只是在事後把它新增進來。這顯然是不可取的，因為測試不僅應該驗證程式碼的正確性，還應該作為程式在不同場景下應如何表現的文件。
在測試 Web 服務時，很少只進行 “純” 單元測試，因為通過 HTTP 進行通訊通常需要呼叫 Spring 的 DispatcherServlet，並檢視當收到一個實際的 HttpServletRequest 時會發生什麼（使它成為一個 “整合” 測試，處理驗證、序列化等）。REST Assured，一個用於簡化測試REST服務的 Java DSL，在 MockMVC 之上，已經被證明提供了一個非常優雅的解決方案。考慮以下帶有依賴項注入的程式碼片段：
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {
Application.class,
SampleUnitTestConfig.class
})
public class RestAssuredTestDemonstration {
@Autowired
private TopTalentController topTalentController;
@Test
public void shouldGetMaryAndJoel() throws Exception {
// given
MockMvcRequestSpecification givenRestAssuredSpecification = RestAssuredMockMvc.given()
.standaloneSetup(topTalentController);
// when
MockMvcResponse response = givenRestAssuredSpecification.when().get("/toptal/get");
// then
response.then().statusCode(200);
response.then().body("name", hasItems("Mary", "Joel"));
}
}SampleUnitTestConfig 類將 TopTalentService 的模擬實現連線到 TopTalentController 中，而所有的其他類都是通過掃描應用類所在包的下級包目錄來推斷出的標準配置。RestAssuredMockMvc 只是用來設定一個輕量級環境，並向 /toptal/get 端點傳送一個 GET 請求。
11. 成為 Spring 大師
Spring 是一個功能強大的框架，很容易上手，但需要一些投入和時間才可以完全掌握。長遠來看，花時間熟悉框架肯定會提高你的生產力，並最終助你寫出更乾淨的程式碼，成為更好的開發人員。
想尋找更多資源，Spring In Action 是一本涵蓋了很多 Spring 核心主題的優秀實戰書籍。
原文：https://www.toptal.com/spring/top-10-most-common-spring-framework-mistakes
作者：Toni Kukurin
譯者：萬想