2013-08-24 80 views
1

閱讀slow compiler and Martin Odersky's response之後,我們非常擔心使用Scala語言啓動大規模ERP產品(這是大量資金用於特定行業)。使用Scala語言的海量ERP系統

根據以下回復進行編輯:拆分爲不同模塊是一種選擇。但是,這就是人們應該如何在大型項目中進行/計劃的方式。這不能成爲我們的解決方案。

Martin本人承認(請參閱上面的鏈接),Java編譯器比Scala(差不多兩年前)快10倍。這對我們來說是可怕的,我們不能在Dev的機器上等待幾個小時的時間(例如,當我們做完整的構建時)。馬丁明確表示,未來不會有任何奇蹟。


我們唯一的選擇是使用連續編譯。我們預期的IDE是IntelliJ Idea。

  1. 我不確定它將如何影響開發人員的機器/ IDE的性能?
  2. 另外,當我點擊保存,它是否也嘗試編譯我目前正在寫的代碼文件?

一些指導真的很感激。

感謝
的Mk

+0

慢編譯器的這個問題在2010年被問到,你真的認爲在這三年中沒有任何改變? – 4lex1v

+0

感謝您的評論。它肯定有改進。但按照馬丁的回答,它仍然會很緩慢,不會指望未來會有任何奇蹟。 –

+1

嗯,我可以說我們正在開發,而不是一個巨大的,但約10個模塊,在Akka + Spray頂部的醫療保健RESTful系統,目前在Jenkins上進行清潔/編譯/測試任務需要大約25分鐘 – 4lex1v

回答

2

編譯速度絕對是Scala的強項不是一個,而是可以潛在地限制多少由構成大項目爲一組較小的一個樹狀的依賴會影響你(核心實用程序;僅依賴於這些實用程序的核心庫;依賴於核心和外部數據庫庫的數據庫接口;等等)。然後,在大多數開發週期中,您可以假裝您正在處理較小的項目,併爲相對較少的事件預留較大的構建版本。

我最大的項目相當小(編譯時間少於5分鐘; LOC爲40k),但即使如此,我也以這種方式進行了細分,這意味着我很少需要等待超過一分鐘才能完成任何事情。它確實需要一些紀律來維護,並且一些重構(因爲我將常見的代碼塊從樹的葉子,快速重新編譯到一個根,而不是複製它),但對我來說工作得很好。