如何挑選稱心的非Java語言?

一旦決定在專案中實驗非Java語言，就要先把專案中的各個工作域分清楚：哪些屬於穩定層、哪些屬於動態層或特定領域層。表7-2中給出了分屬各層的工作。

表7-2 適合穩定層、動態層或特定領域層的專案域

名稱	說明
特定領域層	構建、持續整合、持續部署 開發操作 企業整合模式建模 業務規則建模
動態層	快速Web開發 原型 互動式管理與使用者控制檯 指令碼 測試 （比如用於測試驅動或行為驅動的開發）
穩定層	併發程式碼 應用容器 核心業務功能

如你所見，這些備選語言的使用範圍非常廣泛。但確定用備選語言解決哪項工作只是開始，接下來還要評估用備選語言是否合適。下面是幫我們選擇技術的一些標準。

• 是否為專案裡的低風險區。
• 備選語言跟Java的互動操作是否容易。
• 備選語言是否有工具支援（如IDE支援）。
• 語言學習難度。
• 招聘這門語言的開發人員的難度。

我們會逐一深入探討這些標準。對於自己應該回答的問題，你得做到心中有數。

低風險

假設你有一個核心的支付處理規則引擎，每天要處理一百萬筆交易。這是一個大概執行了七年、穩定的Java軟體，但並沒做過太多測試，程式碼裡有大量死角。對於引入新語言來說，支付處理引擎顯然是高危區，更不用說它本來跑得好好的，而且測試沒做到全面覆蓋，開發人員也還沒完全弄明白它是怎麼回事兒。

但系統不可能只有核心部分。比如更完善的測試明顯會對系統有幫助。Scala有一個非常好的測試框架：ScalaTest，可以用來測試Java或Scala程式碼。開發人員能用它寫出跟JUnit相似但簡潔得多的測試程式碼。所以一旦度過了ScalaTest的學習曲線，開發人員就能非常高效地增加測試覆蓋面。而且ScalaTest對於逐步在程式碼庫中引入行為驅動開發這樣的概念很有辦法。在將來要對核心的某些部分進行重構或替換時，不管最終新的處理引擎是用Java還是用Scala寫，能用上現代測試特性真的很有幫助。

或者假設你需要建一個Web控制檯，以便操作員能管理支付處理系統後臺一些不太重要的靜態資料。開發人員都知道Struts和JSF，可對這兩種技術都提不起興趣。這是另外一個試用新語言和技術棧的低風險區。Grails是個很搶眼的選擇（基於Groovy的Web框架，受Ruby on Rails啟發）。開發人員在經過一些研究後（Matt Raible也做過一個非常有趣的調研），一致認為Grails是生產率最高的Web框架。

因為是集中在低風險區的有限試點上做實驗，如果所嘗試的技術棧不適合自己的團隊或系統，經理可以隨時終止專案，不用中斷太久就可以轉移到不同的交付技術上。

與Java的互動操作

你肯定不想把原來寫的那些Java程式碼棄之不用！很多組織都是因為這個原因遲遲不肯引入新的程式語言。但因為備選語言是跑在JVM上的，所以可以充分發揮原有程式碼的作用，這樣問題變成了怎麼讓已有程式碼庫的價值最大化，而不是拋棄正在使用的程式碼。

JVM上的備選語言跟Java之間的互操作簡單利落，當然也能部署到原先的環境中。在討論這個問題時一定要請管理生產環境的同仁到場參與。在把非JavaJVM語言加入到系統中時，你需要充分運用他們的專業經驗。這也有助於消除他們對支援新方案的擔憂，還能降低風險。

注意 DSL一般都是用動態層語言構建的（某些情況下也有穩定層語言），所以它們大多數是通過其內建語言執行在JVM上。

有些語言跟Java互動操作起來更容易。我們發現最流行的JVM備選語言（比如Groovy、Scala、Clojure、Jython和JRuby）都跟Java互操作得很好（而且其中某些語言的整合做得非常棒，幾乎天衣無縫）。如果你確實是個謹小慎微的人，可以先做幾個實驗，很快，也很容易，而且你肯定能明白整合是如何工作的。

我們以Groovy為例。在Groovy程式碼裡可以用我們熟悉的import語句直接匯入Java包。用基於Groovy的Grails框架可以快速搭建一個網站，而引用物件仍然是Java模型物件。反過來說，在Java程式碼裡呼叫Groovy程式碼也非常容易，有各種各樣的辦法，得到的也是熟悉的Java物件。比如從Java裡呼叫Groovy程式碼處理JSON資料，並讓它返回一個Java物件。

良好的工具和測試支援

大多數開發人員一旦習慣了已有環境，就會低估他們能節省的時間。有強大的IDE和構建工具、測試工具幫他們快速生產出高質量的軟體。Java開發人員多年來受益於優秀的支援工具，所以一定要記得其他語言的成熟度可能還沒達到相同的水平。

有些語言（比如Groovy）在編譯、測試和最終結果部署方面長期以來都有IDE的支援。而其他語言的工具可能羽翼未豐。比如說Scala的IDE就不像Java的那麼好用，但Scala粉覺得它的強大和簡潔完全可以彌補當前IDE的不足。

還有個相關的問題，當備選語言社群開發出供自己使用的強大工具（比如Clojure的構建工具Leiningen）後，可能不太好調整它去處理其他語言。這就是說開發團隊要認真考慮該如何分配專案，特別是在部署各自獨立但又相互關聯的元件時。

備選語言學習難度

學一門新語言總歸需要時間，而且如果開發團隊不熟悉該語言的正規化，時間會更長。如果新語言是物件導向的，並有類C的語法（比如Groovy），那大多數Java開發團隊都能輕鬆掌握。

可如果偏離了這一正規化，偏離程度越大，Java開發人員覺得越難學。Scala試圖在物件導向和函式式兩個世界之間架起一座橋樑，但這種融合對於大規模軟體專案是否可行仍然沒有定論。在特別流行的幾種備選語言中，Clojure可能會帶來不可思議的好處，但開發團隊在學習Clojure的函式式屬性和Lisp語法時，也需要非常多的再培訓工作。

還有一種選擇是看看重新實現已有語言的JVM語言。Ruby和Python都是非常成熟的語言，有大量的材料可供開發人員學習。這些語言的JVM替身對於想採用易學的非Java語言的開發團隊來說，是不錯的起點。

使用備選語言的開發者

組織必須考慮現實情況：他們不可能總能僱到前2%的人（不管他們在廣告裡怎麼忽悠），而且開發團隊的成員也不會整年一成不變。某些語言，比如Groovy和Scala，已經足夠成熟了，所以有相當的開發人員可以招募。但像Clojure這樣還在想辦法推廣自己的語言，要找到優秀的Clojure開發人員仍然不太容易。

警告 對重新實現的語言的警告：比如說，很多現有的用Ruby寫的包和應用程式，只在原始的基於C的實現下測試過。這就是說要在JVM上使用它們可能會有問題。在選擇平臺時，如果你計劃採用整個用重新實現的語言編寫的技術棧，那就應該把額外的測試時間考慮在內。

重新實現的語言（JRuby、Jython等）在這個問題上很可能再一次發揮作用。簡歷上有JRuby的開發人員可能很少，但因為它就是JVM上的Ruby，而Ruby開發人員非常多（熟悉C版本的Ruby開發人員很容易掌握在JVM上執行導致的差異）。

要理解備選JVM語言的設計選擇及限制，你要先理解JVM如何支援多種語言。