自使用Java十五年后，我寫(xiě)第一本Kotlin書(shū)到現(xiàn)在已經(jīng)快五年了。

我們的團(tuán)隊(duì)沒(méi)有遵循典型的Java手冊(cè)：我們使用Utterlyidle而不是Spring，并采用Totallylazy的函數(shù)式編程方法。我們是IntelliJ的忠實(shí)擁護(hù)者，并試圖充分利用它為Java提供的工具。

那時(shí)，我們的眼光已經(jīng)超越了Java。有一些團(tuán)隊(duì)對(duì)Scala感興趣，我們已經(jīng)用它編寫(xiě)了一些服務(wù)。但是，與Java代碼庫(kù)一起工作的復(fù)雜性、痛苦以及緩慢的構(gòu)建時(shí)間，使得這種語(yǔ)言對(duì)我們大多數(shù)人都沒(méi)有吸引力。

當(dāng)谷歌在2017年宣布Kotlin將成為Android開(kāi)發(fā)的官方語(yǔ)言時(shí)，另一個(gè)與我們關(guān)系密切的團(tuán)隊(duì)在他們的服務(wù)器端開(kāi)發(fā)中評(píng)估了這種語(yǔ)言。最終，我們中的大多數(shù)人都嘗試了一下。

Kotlin對(duì)我們代碼庫(kù)的影響令我震驚。它讓人感覺(jué)更有成效，更安全，而且工具雖然沒(méi)有Java那么成熟，但也足以讓我們值得采用。

從感覺(jué)陳舊和冗長(zhǎng)的語(yǔ)言中解脫出來(lái)，并發(fā)現(xiàn)哪些編碼風(fēng)格非常適合Kotlin的特性，也是一件有趣的事情。與Java的出色互操作性意味著我們可以增量地依賴(lài)現(xiàn)有的生態(tài)系統(tǒng)和過(guò)渡系統(tǒng)，而不會(huì)對(duì)完成工作造成重大干擾。

很快，我就對(duì)Kotlin產(chǎn)生了興趣，共同創(chuàng)建了http4k，一個(gè)用于Kotlin HTTP應(yīng)用的函數(shù)式工具包，并舉辦了“真實(shí)世界Kotlin開(kāi)發(fā)研討會(huì)”，幫助其他團(tuán)隊(duì)進(jìn)行同樣的轉(zhuǎn)型。

最終，我已經(jīng)轉(zhuǎn)到了其他崗位，但很幸運(yùn)地看到了Kotlin在其他各種項(xiàng)目的服務(wù)器端的應(yīng)用。而我也親身經(jīng)歷了一些團(tuán)隊(duì)強(qiáng)烈不愿意采用Kotlin的原因。

很奇怪的是，阻力并不總是來(lái)自于實(shí)際語(yǔ)言的優(yōu)劣。那么，為什么Java服務(wù)器端社區(qū)沒(méi)有更大程度地采用Kotlin呢?

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

我們沒(méi)有時(shí)間學(xué)習(xí)一種新語(yǔ)言

這就是我們?cè)谲浖?xiàng)目中常見(jiàn)的“忙著砍柴，忙著磨斧頭”的變種。這通常是更深層次問(wèn)題的征兆，如不斷增加的技術(shù)債務(wù)和一般的生產(chǎn)力問(wèn)題。

健康的軟件項(xiàng)目總是需要相當(dāng)數(shù)量的學(xué)習(xí)。而一個(gè)稱(chēng)職的Java開(kāi)發(fā)人員可以在幾個(gè)小時(shí)內(nèi)掌握Kotlin的基礎(chǔ)知識(shí)，并在幾天內(nèi)就會(huì)有合理的生產(chǎn)力。

當(dāng)他們寫(xiě)出更簡(jiǎn)單的代碼和處理更少的問(wèn)題時(shí)，因?yàn)樾碌恼Z(yǔ)言而提高生產(chǎn)力，這是一項(xiàng)值得的投資。

每個(gè)版本的Java都在不斷完善

這是真的：Java正在變得更好。而且發(fā)布的速度也越來(lái)越快。另一方面，在處理空性這樣的簡(jiǎn)單事情上，它仍然遠(yuǎn)遠(yuǎn)落后于Kotlin。

也許Java社區(qū)已經(jīng)習(xí)慣了這種語(yǔ)言的發(fā)展速度。盡管如此，Kotlin仍然提供了一種方法，可以在他們的項(xiàng)目中利用這些特性中的許多(以及更多)。

作為Java開(kāi)發(fā)人員，我們感到很高興

這種阻力是最棘手的。如果一個(gè)程序員把自己的職業(yè)身份綁在單一的編程語(yǔ)言上，那就沒(méi)什么辦法了。

一方面，如果Java開(kāi)發(fā)人員不想賭上自己的事業(yè)，跳進(jìn)一門(mén)新語(yǔ)言的未知領(lǐng)域，我可以理解?；蛘咚麄兿氤蔀橐幻L(zhǎng)期的專(zhuān)家，這很公平。

另一方面，我還沒(méi)有看到Java開(kāi)發(fā)人員因?yàn)槭褂肒otlin而“落后”。相反，這表明他們一直在尋找適合自己工作的最佳工具，這是一個(gè)積極的特質(zhì)，至少對(duì)我?guī)椭衅傅娜藖?lái)說(shuō)是這樣。

Kotlin是一門(mén)炒作高漲的語(yǔ)言，前途未卜

這是我們?cè)?017年前后看到的一個(gè)常見(jiàn)的反對(duì)意見(jiàn)。在那一年，谷歌接受了Kotlin作為Android開(kāi)發(fā)的一流語(yǔ)言，讓我們放心，大玩家們對(duì)這門(mén)語(yǔ)言的長(zhǎng)久發(fā)展很感興趣。

今天，這種情況可能不太常見(jiàn)，因?yàn)橄馭pring和Micronaut這樣的流行框架似乎已經(jīng)接受了新語(yǔ)言。

希望能給這門(mén)語(yǔ)言足夠的知名度，讓更多服務(wù)器端的人嘗試一下。

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

可以公平地說(shuō)，Eclipse中的Kotlin體驗(yàn)可能與JetBrains IDEA不符。

這是可以理解的，因?yàn)镴etBrains的商業(yè)模式包括出售其開(kāi)發(fā)人員工具。而且這種情況不太可能很快改變。

他們唯一的希望是Kotlin達(dá)到一個(gè)臨界質(zhì)量，從而證明對(duì)Eclipse支持的進(jìn)一步投資是合理的。在此之前，對(duì)于Kotlin開(kāi)發(fā)人員來(lái)說(shuō)，最好的開(kāi)發(fā)體驗(yàn)仍將停留在JetBrains產(chǎn)品上。

我的觀點(diǎn)是IntelliJ已經(jīng)是一個(gè)更好的Java IDE了，所以它也值得一試。

Kotlin開(kāi)發(fā)人員太昂貴了，很難獲得

很難評(píng)估這一點(diǎn)：在薪金網(wǎng)站上，可以得出結(jié)論，Kotlin的薪水總體上略高。

如果我們只想考慮服務(wù)器端開(kāi)發(fā)人員，那就很難比較了。一般來(lái)說(shuō)，那是Java領(lǐng)域工資最高的領(lǐng)域，Kotlin方面的數(shù)據(jù)還不夠多，無(wú)法比較。

坊間傳聞，我們?cè)趯?shí)踐中看到，資深的Java開(kāi)發(fā)人員往往是最早采用Kotlin的人，這可能會(huì)給人一種Kotlin開(kāi)發(fā)人員很貴的印象。

在招聘方面，我們還沒(méi)有看到吸引Kotlin開(kāi)發(fā)人員的問(wèn)題。我們明確工作需要使用新語(yǔ)言，并接受開(kāi)發(fā)人員在工作中學(xué)習(xí)新語(yǔ)言。

這似乎能讓Java開(kāi)發(fā)人員安心，吸引那些熱衷于學(xué)習(xí)新東西的人，這也是一個(gè)潛在的合適指標(biāo)。

Kotlin太復(fù)雜了

Kotlin之所以能成為Scala等語(yǔ)言的一個(gè)引人注目的替代品，原因之一是它在開(kāi)發(fā)者的易用性和高級(jí)特性之間取得了適當(dāng)?shù)钠胶?，使其與Java的可操作性和被流行框架采用成為可能。

在實(shí)踐中，這種異議往往與個(gè)人團(tuán)隊(duì)的技能、風(fēng)格、慣例有關(guān)。

初學(xué)者往往會(huì)像編寫(xiě)Java一樣開(kāi)始編寫(xiě)Kotlin。隨著他們對(duì)這門(mén)語(yǔ)言越來(lái)越熟悉，他們很可能會(huì)把一些功能(如擴(kuò)展和內(nèi)聯(lián)函數(shù))推得太遠(yuǎn)，使得代碼庫(kù)對(duì)新手來(lái)說(shuō)難以理解。

在團(tuán)隊(duì)完全勝任新語(yǔ)言之前，我們強(qiáng)烈主張盡可能長(zhǎng)時(shí)間地使用Boring Kotlin(TM)。最終，大多數(shù)團(tuán)隊(duì)都會(huì)在挑選很酷的語(yǔ)言特性和讓整個(gè)團(tuán)隊(duì)都能使用代碼之間找到平衡點(diǎn)。

在一個(gè)代碼庫(kù)中使用兩種語(yǔ)言令人困惑

那些沒(méi)有在實(shí)際項(xiàng)目中嘗試過(guò)Kotlin的人們普遍擔(dān)心。

在實(shí)踐中，只要團(tuán)隊(duì)認(rèn)同并注意到新的Kotlin代碼一開(kāi)始需要與Java共存，在一個(gè)項(xiàng)目中使用兩種語(yǔ)言并不會(huì)帶來(lái)明顯的痛苦。

一個(gè)可以幫助的規(guī)則是："如果改動(dòng)涉及到兩種語(yǔ)言，首先要把舊的代碼轉(zhuǎn)換成Kotlin"。

這樣一來(lái)，團(tuán)隊(duì)就可以避免大刀闊斧的重寫(xiě)，而逐步遷移需要增加新價(jià)值的地方。

如果有些代碼還保留在Java中，那也沒(méi)關(guān)系。很有可能是因?yàn)榇a還能用，沒(méi)有迫切的需要重構(gòu)。

我們對(duì)Java感到更自在

在實(shí)踐中，可能是特定的上下文不需要新的語(yǔ)言。一切都很好;團(tuán)隊(duì)以可接受的速度完成了事情，并且很好地掌握了Kotlin將幫助解決的問(wèn)題。

然而，根據(jù)我們的經(jīng)驗(yàn)，這是例外而不是常規(guī)。更多的時(shí)候，這種阻力源于普遍缺乏時(shí)間或?qū)W習(xí)興趣，而不是缺乏需要改進(jìn)的地方。

在嘗試真正的項(xiàng)目之前，也很難體會(huì)到Kotlin的好處，引入一門(mén)新的語(yǔ)言，即使是作為實(shí)驗(yàn)，也會(huì)引起很多焦慮。

在這些情況下，我們推薦 "在職學(xué)習(xí)"(以編碼dojos、布朗包會(huì)議等形式)，以創(chuàng)造一個(gè)安全的環(huán)境，讓這種實(shí)驗(yàn)?zāi)軌虬l(fā)生。

這種方法可以讓團(tuán)隊(duì)評(píng)估他們對(duì)Java的使用和是否值得投資Kotlin。

我不知道Kotlin會(huì)帶來(lái)什么優(yōu)勢(shì)

有時(shí)，Java開(kāi)發(fā)人員不知道語(yǔ)言的局限性，或者太習(xí)慣于這些局限性。其他時(shí)候，他們會(huì)拒絕任何讓他們質(zhì)疑當(dāng)前選擇的語(yǔ)言的選擇。

我們不細(xì)說(shuō)，可以說(shuō)Kotlin的簡(jiǎn)潔和安全是它的主要優(yōu)勢(shì)。然而，有些人會(huì)說(shuō)他們不認(rèn)為Java的啰嗦有問(wèn)題，寫(xiě)出的代碼已經(jīng)很安全了。

在嘗試之前很容易否定Kotlin，當(dāng)面臨選擇時(shí)，少數(shù)人會(huì)繼續(xù)尋找理由不嘗試。

最后的想法

采用一種新的編程語(yǔ)言，尤其是在進(jìn)行中的項(xiàng)目中，對(duì)大多數(shù)團(tuán)隊(duì)來(lái)說(shuō)都是一種挑戰(zhàn)。同樣重要的是要接受這樣的事實(shí)，即對(duì)變革的抵觸情緒與具體情況密切相關(guān)，它將來(lái)自項(xiàng)目需求和個(gè)人原因以及語(yǔ)言本身。

說(shuō)了這么多，我還是鼓勵(lì)更多從事Java服務(wù)器端工作的開(kāi)發(fā)者，如果有機(jī)會(huì)的話，可以嘗試一下Kotlin。如果沒(méi)有別的原因，它可能會(huì)突出代碼之外的其他改進(jìn)領(lǐng)域。