爲什麼 Java 後端開發沒有大規模採用 Kotlin？

作者 | Ivan Sanchez

譯者 | 王者

策劃 | 萬佳

由於自滿、職業上的自我保護和缺乏可見性等原因，在服務器端採用 Kotlin 的進展速度非常慢。不過，在某些特定情況下，避免採用 Kotlin 是完全合理的。

2017 年，谷歌宣佈 Kotlin 成爲 Android 的官方開發語言，另一個與我們關係密切的團隊開始評估是否可以在他們的服務器端開發中使用它。最後，我們大多數人都去嘗試了一下。

我被 Kotlin 給代碼庫帶來的影響震撼到了。它給人的感覺是更高效、更安全，雖然開發工具沒有 Java 那麼成熟，但也足夠好了。

從一門陳舊而冗長的編程語言中解脫出來，並探索哪些編碼風格更適合 Kotlin 的特性，這本身就是一件非常有趣的事情。Kotlin 與 Java 出色的互操作性意味着我們可以增量地依賴現有的生態系統和過渡系統，而不會對工作造成重大幹擾。

很快，由於對 Kotlin 的興趣，我們一起開發了 http4k，一個用於開發 Kotlin HTTP 應用程序的工具包，並組織了 Kotlin 開發研討會，幫助其他團隊嘗試使用 Kotlin。

最後，我們看到其他各種項目也在服務器端使用 Kotlin，也看到了一些團隊強烈不願意採用 Kotlin 的原因。

有意思的是，這種抗拒並不總是因爲編程語言本身。那麼，爲什麼 Java 服務器端開發社區沒有更多地採用 Kotlin 呢？

以下是我和我的同事們看到的一些原因。

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

這也就是我們在軟件開發項目當中經常看到的 “忙着砍柴沒時間磨斧子” 現象。這通常預示着更深層次問題，比如不斷增加的技術債務和開發效率問題。

健康的軟件項目需要開發者花大量時間去學習。一個有能力的 Java 開發者可以在數小時內掌握 Kotlin 的基本知識，並在數天內提高開發效率。

如果採用新語言可以讓他們寫的代碼更簡單，遇到的問題更少，那麼投入就是值得的。

這是真的，Java 正在變得更好，而且發佈的速度也越來越快。但是，對於處理空值這麼簡單的事情，仍然遠遠落後於 Kotlin。

也許 Java 社區已經習慣了這種演化速度。儘管如此，Kotlin 還是提供了一種方法，可以在項目中用上很多 Kotlin 特性。

 “作爲 Java 開發者，我們感到很自豪”

這種想法是最要命的。如果一個程序員把他們的專業身份和一種編程語言聯繫在一起，那就沒有辦法了。

如果說 Java 開發者不想賭上自己的事業踏入一門新語言的未知領域，我可以理解。或者他們可能想成爲一個領域的專家，這也很合理。

但是，我也並沒有看到哪個 Java 開發者因爲使用 Kotlin 而 “落後” 了。相反，這表明他們一直在尋找適合自己的工具，這是一種積極的特質。

 “Kotlin 是一種被炒作的語言，它的未來是未知的”

這是我們在 2017 年經常聽到的反對採用 Kotlin 的說法。在那一年，谷歌宣佈將 Kotlin 作爲 Android 的官方開發語言，讓我們確信科技巨頭們對這門語言是感興趣的。

現在，Spring 和 Micronaut 等流行框架似乎已經接受了這門新語言，之前的反對聲就不那麼經常聽到了。

希望這能讓更多的服務器端開發對這門語言有足夠的瞭解，並嘗試一下。

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

在 Eclipse 中使用 Kotlin 的體驗與 JetBrains 的 IDEA 不太一樣。

這是可以理解的，因爲銷售開發工具是 JetBrains 的商業模式之一，而且這種情況短期內不太可能改變。

對於這些人來說，他們能夠期望的是 Kotlin 可以達到一個質量臨界點，證明 Eclipse 爲它提供進一步的支持是值得的。但在此之前，對於 Kotlin 開發者來說，最好的開發體驗仍然是使用 JetBrains 產品。

我認爲，IntelliJ 已經是一個更好的 Java IDE 了，所以它也值得一試。

 “Kotlin 開發者太貴了，而且很難招到”

這一點很難說，從招聘網站的數據來看，Kotlin 開發者的薪資總體上略高一些。

如果我們只考慮服務器端開發者，就很難進行比較。一般來說，Java 開發者的薪資是最高的，但在 Kotlin 方面並沒有足夠的數據來進行比較。

有趣的是，在實際當中，我們可以看到高級 Java 開發者經常是率先採用 Kotlin 的人，這可能會給人留下 Kotlin 開發者很 “貴” 的印象。

在招聘方面，我們並沒有覺得很難招到 Kotlin 開發者。我們很清楚，有些工作需要使用這門新語言，並允許開發者在工作中邊學邊用。

這似乎讓 Java 開發者放下心來，並吸引了那些熱衷於學習新事物的人。

 “Kotlin 太複雜了”

Kotlin 之所以成爲 Scala 等語言的替代語言，其中一個原因是它在易用性和高級特性之間取得了良好的平衡，與 Java 具有更好的互操作性，所以更有可能被流行框架採用。

在實際當中，這種反對聲與團隊的技能、風格和習慣有關。

初學者一般會像使用 Java 一樣使用 Kotlin，但隨着他們越來越熟悉這門語言，可能會深入使用一些特性 (例如擴展和內聯函數)，從而導致代碼庫變得越來越難以理解。

在團隊完全掌握新語言之前，我們建議儘可能長時間地使用普通的 Kotlin 特性。最後，團隊中的大多數人都會在選擇很酷的語言特性和保持代碼庫易於理解之間找到平衡點。

 “在一個代碼庫中使用兩種語言讓人感到困惑”

這是在實際項目中沒有嘗試過 Kotlin 的人經常會有的擔憂。

在實際當中，當團隊意識到新的 Kotlin 代碼需要與 Java 共存，那麼在一個項目中使用兩種語言並不會給他們造成很大的痛苦。

這裏有一個有用的規則：“如果一個變更涉及到兩種語言，首先將舊代碼轉換成 Kotlin”。

這樣，團隊就可以避免大爆炸式的重寫，並將需要添加新特性的地方進行逐步遷移。

如果需要保留一些 Java 代碼，那也沒關係。很有可能是因爲這些代碼仍然有用，並且沒有進行重構的迫切需求。

在實際當中，有一些場景不一定要使用 Kotlin，一切仍然能夠進行得很順利，團隊能夠以可接受的速度完成工作。

然而，根據我們的經驗，這是例外，而不是常態。通常情況下，這種對語言的抗拒源於缺少時間和興趣，而不是因爲沒有可提升的空間。

如果沒有在真正的項目中使用 Kotlin，是也很難體會到 Kotlin 的好處的。即使是作爲一個實驗，也存在很多焦慮。

對於這種情況，我們建議 “在工作中邊學邊用”(以編碼道場、培訓等形式)，創造一個可以進行這種實驗的安全環境。

這樣可以幫助團隊評估他們對 Java 的使用狀況，以及是否值得在 Kotlin 上投入。

有時候，Java 開發者意識不到語言方面存在的限制，或者是因爲他們已經習慣了。有時候，他們會抗拒新語言，因爲新語言會讓他們質疑自己正在使用的語言。

在不深入細節的情況下，我們可以說 Kotlin 的簡潔性和安全性是它的主要優點。然而，有些人聲稱他們不認爲 Java 的冗長有什麼問題，並且寫出來的代碼也很安全。

在真正去嘗試 Kotlin 之前，人們很容易將其忽略掉。而在真正面對它的時候，一些人會繼續尋找不嘗試使用它的理由。

 一些想法

採用一種新的編程語言，特別是在正在進行的項目當中，這對於大多數團隊來說都是一個挑戰。對變化的抗拒與特定的環境有關，與項目需求和個人原因以及語言本身也有關。

話雖如此，我仍然鼓勵更多從事 Java 服務器端的開發者，如果有機會的話，可以嘗試一下 Kotlin。

原文鏈接：

https://medium.com/google-developer-experts/why-are-java-server-side-developers-not-adopting-kotlin-8eb53e06ee99

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Y1_YLJ9TijH418uxcqm1sA