9.2 Scala能用在我的項目中嗎

在Java項目裡增加一門語言總該有正當的理由和根據。在這一節，我們希望你想想那些理由，以及如何把它們應用到你的項目中。

一開始我們會快速比較一下Scala跟Java，然後看看什麼時候，以及如何開始使用Scala。為了讓這一篇幅較短的章節更完整，我們會看一些示警信號，當出現這些信號時，Scala可能不是最適合你項目的語言。

9.2.1　Scala和Java的比較

我們在表9-1中對這兩種語言的主要差異做了匯總。語言的「表皮層」是指該語言關鍵字的數量和開發人員用它幹活必須掌握的獨立語言結構的數量。

表9-1　比較Scala和Java

特性Java Scala 類型系統靜態的、非常繁瑣靜態的，但使用了大量類型推斷 多語言金字塔層級穩定穩定、動態 並發模型基於鎖機制基於actor機制 函數式編程需要嚴格遵守的特殊編碼方式，不自然內置支持、語言的一部分（純天然） 表皮層小型/中型大型/超大型 語法風格簡單、常規、比較繁瑣靈活、精煉、很多特殊情況

這些差異是Scala得到Java開發人員青睞，可以把它當做某些項目或組件的備選語言的部分原因。接下來我們會給出把Scala引入項目的更多細節。

9.2.2　何時以及如何開始使用Scala

我們在第7章討論過，在已有項目中引入新語言時，最好從風險比較低的區域開始。ScalaTest測試框架（見第11章）就是這樣的低風險區。如果Scala實驗不順利，那所有的成本就是開發人員浪費的時間（這些單元測試有可能變成普通的JUnit測試）。

一般來說，適合在項目中引入Scala的組件應該基本滿足下面這些條件：

• 你有信心評估所需的工作量；
• 問題域邊界明確，定義清晰；
• 需求說明正確；
• 與其他組件的互操作性需求已知；
• 確定了願意學習新語言的開發人員。

經過深思熟慮選定合適區域後，你就可以開始實現自己的第一個Scala組件了。下面有些指導原則，事實證明它們能讓初始組件按部就班地進行：

• 以快速扣殺開始；
• 盡早跟已有的Java組件測試交互操作；
• 有定義扣殺成功或失敗的入門標準（基於需求）；
• 如果扣殺失敗，要有B計劃；
• 在預算中為新組件留出額外的重構時間（用新語言編寫的第一個項目欠下的技術債幾乎肯定會比用團隊已經熟悉的語言編寫來得高）。

在評估Scala時，另外一個應該考慮的是檢查那些明顯讓Scala對項目來說不太理想的跡象。

9.2.3　Scala可能不適合當前項目的跡象

下面這些跡象表明Scala可能並不適合你的項目。如果出現了其中一個或多個跡象，你應該慎重考慮引入Scala的時機是否恰當。如果超過兩個，那基本就沒什麼戲了。

• 受到了業務小組和其他程序支持小組的抵制，或缺乏動力。
• 開發團隊沒有明顯的學習Scala的動力。
• 小組中分幫結派或政治上存在巨大分歧。
• 小組中高級技術人員的支持力度不夠。
• 截止日期太緊張（沒時間學習新語言）。

另外一個要密切關注的因素是，團隊是否分散在全球各地。如果你用來開發（或支持）Scala代碼的員工分散在幾個地方，那會增加Scala培訓人員的成本和負擔。

現在我們已經討論過把Scala引入項目的機制了，接下來該去看看Scala的語法了。我們會重點關注讓Java開發人員更輕鬆的特性，鼓勵更加緊湊的代碼，少點套路化和揮之不去的繁瑣。