Java依然是十五年來的摯愛，框架是業界最佳實踐的沉澱

作者 | 丁雪豐

記者 | 木環

Java 誕生二十餘載，而各有千秋的新語言則層出不窮；平安壹錢包的丁雪豐 15 年前接觸 Java，而他依然最喜愛 Java。那麼為什麼他對 Java 如此篤定呢？而在為數不少的框架中，為什麼他又選中 Spring 框架？Spring 技術有哪些適用和不適用的場景？為了一探究竟，InfoQ 對丁雪豐先生進行了採訪。

此外，丁雪豐先生還將作為演講嘉賓出席中國首屆 Spring Summit 技術峰會，並進行《有了 Spring Boot，內部框架還缺什麼？》的主題分享。此次峰會由 Pivotal 和極客邦科技聯合主辦，會議分設 Spring 生態 10 余個技術主題，邀請了十餘位中美專家，將從從企業上雲、傳統行業在數字經濟時代機遇與挑戰等宏觀戰略層面，以及微服務、DevOps、Reactive、CloudNative Java 等微觀技術層面，來詮釋如何完成企業數字化轉型這道考題。Spring Summit 2017 官網已經上線，各位讀者可以移步了解詳情。

InfoQ： 您從事 Java 開發數年，您怎麼評價這門語言？為什麼 Java 會成為世界上使用者最多的語言？

丁雪豐：我是在 2002 年機緣巧合下開始正式學習並使用 Java 的，在那之前我都在使用微軟系的東西。當時做的 Java 應用很多還是 Applet，在頁面上呈現出酷炫的效果，用 Servlet 和 JSP 做後端服務的還不多。開個玩笑，當時 Java 號稱「write once, run anywhere」，我天真地相信了，後來才理解到這真的只是一個美好的願望。不過這並不妨礙 Java 的成功，我本人也是一名堅定的 Java 用戶（雖然我經常會去學習各種新語言，但主要工作語言一直是 Java），如果翻看這幾年的 TIOBE 排行榜，你就會發現它長期位居榜首，這就是大家對 Java 的認可。

一門語言好不好是仁者見仁智者見智的事。不過如果一門語言缺乏活力，那要麼就是小眾無人問津，要麼就是開發者也放棄維護了。Java 有著龐大的社區和使用者，雖然出於商業等原因，步伐顯得不如一些新興語言這麼快，但一直在穩步向前發展，同時還在不斷借鑒其他人的經驗，所以有理由相信，Java 在未來的一段時間裡仍然會處在一個很好的位置上。

很多人覺得靜態語言不夠靈活，但我覺得這是 Java 能被眾多軟體廠商接受的重要原因之一，它能夠適用於龐大的研發團隊。試想一下，如果我只能在運行時才知道一個介面返回的是什麼，那上下游之間得要下多少成本來保證傳遞正確的內容？而靜態語言絕大部分內容都是明確的，就算有問題，多數也能在編譯時發現。

另外，我覺得面向對象思想的傳播，也是 Java 被廣泛接受的原因之一，在那個時候說起 OO，大家第一想起的就是 C++ 和 Java。根據 OO 理論設計的系統能夠幾乎「無縫"地用 Java 實現出來，再配合一些工具，代碼生成更是大大提升了開發的效率。在大規模工業化的開發過程中，這是非常重要的。

最後，我想強調一點：通常大家說起 Java 都是指語言，但我們不能把 Java 狹義地理解為 Java 語言，個人認為 Java 這個平台才是關鍵，才是真正獲得成功的東西。 Java 平台的開放和包容，讓它不僅可以運行 Java 語言開發的代碼，還可以運行 Ruby、Python、JavaScript、Scala、Groovy 等很多語言寫的代碼，因此其他語言的開發者可以很輕鬆地切換至 Java 平台。

InfoQ：現在新的語言層出不窮，其中不乏一些深受歡迎的語言。那麼，Java 現在有哪些新的挑戰？您對 Java 9 有怎樣的期待？

丁雪豐：關於這個問題，我以前在 InfoQ 上發表過一篇文章《作為一名 Java 程序員，我為什麼不在生產項目中轉向 Go》，以 Go 語言為例，我認為這是一門非常出色的語言，在一些場景下有著比 Java 更好的表現，但正如我上面說的，Java 不僅是一門語言，更是一個平台，它有著完善的生態環境，很多特性雖然語言本身不具備或者不盡如人意，但生態環境中總有更好的解決方案。

而且，真的在實際的生產中，語言本身往往只是考量的眾多因素之一，我能用某種語言很快地完成一個功能的開發，但能不能讓 10 個人、50 個人都又快又好地以一樣的標準完成開發工作呢？有一套好的設施、工具甚至可執行的標準會容易很多，所以我認為生態環境要比單獨的語言本身更為重要。

說到 Java 9，很多人都會期待模塊化，但其實我更希望 Java 9 出來的時候，Java 8 可以再普及一些。總是會有人覺得新東西不太靠譜，要用低一個版本的東西，覺得用的人多了，經過時間檢驗了。君不見，如今還有很多運行在 Java 6 甚至是 Java 1.4 上的系統，什麼時候能讓大部分人感受到 Java 8 的魅力呢？

InfoQ：能否回溯下 Spring 的進化史？

丁雪豐：說起 Spring 就不得不提 Rod Johnson，Spring 誕生於他的那本《Expert One-on-One J2EE Design and Development 》，而他的另一本《Expert One-on-One J2EE Development without EJB》真正讓 Spring 紅透半邊天。

Spring 最早誕生在 2004 年，個人認為在 2.0 版本以後，也就是上面提到的那本書出版後國內的開發者才大範圍地接受 Spring，當時國內的滿江紅社區還組織翻譯了大量的開源框架的官方文檔，包括了 Spring、Hibernate、Seam 等等，這也在很大程度上推動了這些框架在國內的落地。

（註：Spring 框架是開源的 Java/Java EE 全功能站的應用程序框架，以 Apache 許可證形式發布，由 Pivotal 開發並維護。）

再往後，Spring 的版本不斷迭代，其核心的部分並沒有太多的變化並開始趨於穩定；不過逐步開始發展 Spring 的子項目，誕生了類似於 Spring Data、Spring Batch、Spring Integration 等諸多周邊的子項目，將很多功能都從 Spring Framework 中移到了子項目中。

現在到 Spring 的官方網站上，各種項目不下 20 個，所有的這些子項目中，近期最熱門的當屬 Spring Boot 和 Spring Cloud。這一對搭檔極大程度上降低了使用 Spring 快速開發生產級系統的成本，而且能夠方便地使用各種成熟的技術與設施，使得開發此類系統的門檻大幅降低。

InfoQ：能否向大家介紹下您所理解的 Spring 技術？Spring 框架有怎樣的特點？它最適合怎樣的項目情景？

丁雪豐：Spring 已經不再僅代表一種框架，它與 Java 一樣，都已經有了一個完整的生態環境（比如上文中提到的眾多子項目）。

先聊聊狹義的 Spring，即 Spring 框架。從最開始接觸 Spring 1.x 起，它特有的模塊化設計就讓人感到學習和使用起來沒有負擔，因為我只需要去掌握需要的那些模塊就行了，比如 Spring Core、數據訪問、MVC 等等，至於 Remoting 那些功能，大概有個印象就行，知道它有哪些功能，在需要的時候去翻看相應的文檔就好了。

在後來的演進過程中，Spring 框架變得越來越大，顯得有些臃腫，但開發者們還是只要關心自己要用的那些東西就好，了解下新的特性和用法，而且它在很多情況下還是能夠完美兼容的，所以升級時的負擔也不會很重。

至於其他的特點，網上有很多資料，我就不再在此贅述了。

而廣義的 Spring 則是 Spring 的生態，Spring 將很多功能拆散到眾多子項目中，每個子項目專註於某個特定的功能，比如 Spring Security 就專門處理安全相關的問題。並且，多數子項目都發展得很不錯，市面上至少都能找到基本單獨介紹一個子項目的書。

正如我前面提到的，在所有這些子項目中，Spring Boot 和 Spring Cloud 是近期最為熱門的項目，早期 Spring 還有一個 Spring Roo 的項目，用來生成項目工程和各種代碼，但後來 Spring 團隊發現代碼生成並不是一個特別理想的做法。在 Spring 4.x 引入了大量註解，提升自動化配置能力，Spring Boot 正是在此類能力的基礎之上，大大降低了需要編寫的配置和代碼量，它替開發者做了絕大部分選擇，讓開發者能更專註於業務本身。

個人認為，但凡 Web、後端服務這類的項目都可以放心大膽地使用 Spring Boot，哪怕是一整套項目都使用 Spring Boot 也不會有太多問題。比如國外的 Netflix，國內的淘寶、支付寶，都是幾乎全部由 Java 使用，廣泛使用 Spring 技術，不少也在使用 Spring Boot，甚至是向 Spring Boot 和 Spring Cloud 貢獻代碼。

但 Spring 也不是萬能的，比如涉及硬體的一些場景就沒什麼發揮餘地了，在開發板或者嵌入式設備上，還是選擇更合適的東西吧。

InfoQ：您怎樣看待框架？它是很好的工具，但是一定程度上是不是也有不足和束縛？項目多大之後就建議一定使用框架？

丁雪豐：在我看來，框架要做的事就是把大量最佳實踐固化下來，降低開發者的使用成本，讓大家能聚焦於做什麼，而不是怎麼做。比如 Mina 和 Netty 就把怎麼寫出好的網路通信代碼的經驗固化了下來，Google Guava 就把 Google 里大量 Java 的最佳實踐變成了人人可用的東西。

其實使用框架也確實有束縛，一旦你使用了一種框架，那你的系統在很大程度上來說有被綁定在上面了，切換的成本是非常高的。舉個例子，在存儲層使用了 Hibernate 來做 ORM，之後想完整切換到 myBatis，幾乎就是重寫整個 DAO 的底層。

不過，情況也並非總是這麼糟糕，也有容易的，比如一開始使用 Log4J 1.x 作為日誌框架，後續想切換到 LogBack，不用把所有日誌的包都重新 import 一遍，使用 log4j-over-slf4j 就好了。

至於項目多大之後使用框架，個人認為，在條件允許的情況下，只要能夠幫助降低開發的複雜度，提升效率，無論什麼規模的系統都可以使用合適的框架。

InfoQ：能否和大家分享下您的 Spring 學習歷程？新手是否建議直接學習框架？框架需要理解掌握到什麼程度？學習框架需要源代碼？

丁雪豐：我自己最早就是翻譯Spring 的官方文檔和書籍，從 Spring 1.x 到 2.0，再到 2.5。翻譯的過程讓我對整個 Spring 框架有了比較多的了解，很多功能雖然一時用不上，但翻譯和審校時總是會看個幾遍，於是也能了解個大概。再到後來各種子項目則是在新出來時做個了解，實際工作中需要用到時再詳細閱讀文檔。

另一方面，多做一些分享和交流，準備分享材料的過程也是對自己知識的梳理和總結，會有很多意想不到的收穫。比如，之前準備一個 Spring Cloud 和微服務相關的分享，大部分網站和文章都會拿 Eureka 做例子，我特意去用了下平時不怎麼接觸的 Spring Cloud Consul 服務發現。

至於後面兩個問題，我覺得是水到渠成的事情，不用刻意去糾結。

對於新接觸 Java 的同學，學習基本語法自然是第一步，隨後需要找些小項目來練手了，這時自然就會接觸到一些框架，所以新手接觸並學習框架是件很自然的事情，不用去想該早點或者晚點。

平時把框架用好就行了，遇到問題會有思路去排查和解決。二八法則可以說是普遍適用的，對一個框架了解 20% 就能滿足大部分的日常需求。可這並不能算是用好，因為你總是會碰到些這樣那樣的問題，出現問題時自然就會去翻看對應部分的代碼，所以學習框架的源代碼也是遲早會發生的事情。

8 月 26 日，中國首屆的 Spring 技術大會將盛大啟幕，在這裡你會遇見十餘位中外技術大咖，聆聽 Spring 生態 10 余個技術主題分論壇，一同探討 Spring Boot、Spring Cloud、Cloud Foundry、Cloud Native、DevOps 和微服務的真知灼見和實際案例。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！