谷歌專家：為什麼Java伺服器端開發人員不採用Kotlin？ - Ivan

自使用Java十五年後，我編寫Kotlin的第一行到現在已經快五年了。我們的團隊沒有按照典型的Java劇本：我們用Utterlyidle代替Spring，擁抱了函數語言程式設計方法Totallylazy。我們是IntelliJ的忠實擁護者，並試圖充分利用它為Java提供的工具。

那時，我們已經在尋找Java以外的東西了。一些團隊對Scala表現出了一定的興趣，並且我們已經在其中編寫了一些服務。但是，其複雜性，與Java程式碼庫一起工作的痛苦以及緩慢的構建時間，使得該語言對我們大多數人不受歡迎。

當Google宣佈Kotlin在2017年成為Android開發的官方語言時，與我們關係密切的另一個團隊評估了該語言在其伺服器端開發中的作用。最終，我們大多數人都嘗試了一下。

Kotlin對我們的程式碼庫的影響讓我震驚。它感覺更有生產力，更安全，並且工具雖然還不如Java成熟，但足以使其值得采用。

擺脫一種古老而冗長的語言，並發現哪種編碼風格與Kotlin的功能非常吻合，這也很有趣。與Java的出色互操作性意味著我們可以逐步依賴現有的生態系統和過渡系統，而不會對完成工作造成重大干擾。

不久，我對Kotlin的興趣導致共同建立了http4k（用於Kotlin HTTP應用程式的功能性工具包），並執行了Real World Kotlin開發研討會，以幫助嘗試進行相同過渡的其他團隊。

最終，我到了其他職位，但很幸運看到Kotlin在伺服器端用於其他各種專案。我還親身經歷了很多原因，使得團隊強烈不願意採用Kotlin。

奇怪的是，抵制並不總是源於實際語言的優點。那麼，為什麼Java伺服器端社群沒有更廣泛地採用Kotlin？

我和我的同事遇到的一些原因如下：

“我們沒有時間學習一種新語言。”

健康的軟體專案總是需要大量的學習。一個稱職的Java開發人員可以在數小時內掌握Kotlin的基礎知識，並且幾天之內就可以相當高效地工作。

一旦生產力提高，當他們編寫更簡單的程式碼時，由於採用了新的語言，因此解決了較少的問題，這是一筆值得的投資。

“每個版本的Java都在不斷完善。”

沒錯：Java越來越好。而且釋出的速度更快。另一方面，在處理可空性等簡單的事情上，它仍然落後於Kotlin。

也許Java社群已經習慣了該語言的發展速度。儘管如此，Kotlin提供了一種在今天而不是明天的專案中利用其中許多功能（以及更多功能）的方法。

“作為Java開發人員，我們感到很高興。”

這種抵抗是最棘手的。如果程式設計師將他們的專業身份與一種程式語言聯絡在一起，那就無能為力了。

一方面，我瞭解Java開發人員是否不想通過跳入新語言的未知領域來賭博自己的職業。或者他們想成為長期專家。這很公平。

另一方面，我還沒有看到Java開發人員“落後”，因為他們使用的是Kotlin。相反，這表明他們一直在尋找最適合自己工作的工具，這是一個積極的特徵，至少在我幫助僱用的人身上。

“Kotlin是一門炒作高漲的語言，前景不明。”

這是我們在2017年左右遇到的普遍反對意見。在那一年，Google接受Kotlin作為Android開發的一流語言，從而使我們確信，大公司對這種語言的長久發展很感興趣。

如今，鑑於諸如Spring和Micronaut之類的流行框架似乎已經接受了這種新語言，這種觀點可能已經不那麼普遍了。

希望這將使該語言具有足夠的可視性，以供更多伺服器端人員嘗試。

“我正在使用Eclipse，並且不想切換到IntelliJ。”

可以公平地說，Eclipse中的Kotlin經驗可能與JetBrains IDEA不符。

這是可以理解的，因為JetBrains的業務模型包括出售其開發人員工具。而且這不太可能很快改變。

對於這些，唯一的希望是Kotlin達到了一個臨界點，這證明了對Eclipse支援進行進一步投資的合理性。在此之前，對於Kotlin開發人員而言，最佳的開發人員體驗將保留在JetBrains產品上。

我非常有偏見的觀點是，無論如何，IntelliJ已經是Java更好的IDE，因此值得嘗試一下該開關。

“ Kotlin開發人員太昂貴了，很難獲得。”

很難評估這一點：在薪金網站上，可以得出結論，科特林的薪水總體上略高。

如果我們只考慮伺服器端開發人員，那將是一個艱難的比較。通常，這是Java領域中費用最高的領域，並且Kotlin方面沒有足夠的資料可比較。

有趣的是，在實踐中，我們看到高階Java開發人員通常是最早採用Kotlin的人員，這可能給人以Kotlin開發人員昂貴的印象。

在招聘方面，我們還沒有發現吸引Kotlin開發人員的問題。我們很清楚，這項工作需要使用新的語言，並接受開發人員將在工作中學習它。

這似乎使Java開發人員放心，並吸引了那些熱衷於學習新事物的人，這也是潛在的契合度。

“Kotlin太複雜了。”

Kotlin之所以比Scala之類的語言更吸引人的原因之一是，它在開發人員的易用性和高階功能之間取得了不錯的平衡，以使Java的可操作性和流行框架的採用成為可能。

在實踐中，這種異議往往與各個團隊的技能，風格和慣例有關。

初學者傾向於像編寫Java一樣開始編寫Kotlin。隨著他們對語言的適應性提高，他們可能會將某些函式（例如擴充套件和行內函數）推開了，從而使新手難以理解程式碼庫。

在一個團隊完全掌握新語言之前，我們強烈建議儘可能長時間使用Boring Kotlin（TM）。最終，大多數團隊將足夠舒適地在選擇出色的語言功能和使整個團隊都可以訪問程式碼之間找到平衡。

“在一個程式碼庫中使用兩種語言令人困惑。”

那些沒有在實際專案中嘗試過Kotlin的人們普遍擔心。

在實踐中，只要團隊參與並記住新的Kotlin程式碼首先需要與Java共存，則在單個專案中使用這兩種語言不會帶來很大的麻煩。

一個有用的規則是：“如果更改涉及兩種語言，則首先將舊程式碼轉換為Kotlin”。

這樣，團隊就可以避免大規模的重寫，並逐步遷移他們需要增加新價值的領域。

如果Java中保留了一些程式碼，那也是可以的。這很可能是因為程式碼有效，並且沒有迫切需要對其進行重構。

“我們對Java感到更自在。”

實際上，可能是給定的上下文不要求使用新語言。一切正常。團隊正在以可接受的速度完成工作，並且很好地把握了Kotlin將幫助解決的問題。

但是，根據我們的經驗，這是例外，而不是規則。通常，這種抵制來自普遍缺乏時間或對學習的興趣，而不是缺乏需要改進的地方。

在嘗試一個真實的專案之前，還很難體驗到Kotlin的好處，並且引入一種新的語言（即使作為實驗）也可能引起很多焦慮。

在這種情況下，我們建議您“在工作中學習”（以編碼dojos，棕色皮包課程等形式）來建立一個安全的環境，在這種環境下可以進行此類實驗。

這種方法使團隊可以評估他們對Java的使用以及是否值得在Kotlin上進行投資。

“我不知道Kotlin會帶來什麼優勢。”

有時，Java開發人員沒有意識到語言限制，或者已經習慣了它們。在其他時候，他們會忽略任何使他們質疑當前選擇語言的選擇。

無需贅述，可以說Kotlin的簡潔性和安全性是它的主要優勢。但是，有些人會聲稱他們沒有看到Java的冗長性問題，並且已經編寫了安全的程式碼。

在嘗試使用Kotlin之前將其放棄很容易，而且面對這種選擇時，一些人會繼續尋​​找不嘗試的理由。

最後的想法

對於大多數團隊而言，採用一種新的程式語言（尤其是在進行中的專案中）會帶來挑戰。同樣重要的是，要接受對變革的抵制是高度特定於上下文的，並且來自專案需求和個人原因，以及語言本身。

話雖如此，我仍然鼓勵更多的Java伺服器端開發人員在有機會的情況下嘗試Kotlin。