自使用Java十五年后，我寫第一本Kotlin書到現(xiàn)在已經快五年了。
我們的團隊沒有遵循典型的Java手冊：我們使用Utterlyidle而不是Spring，并采用Totallylazy的函數式編程方法。我們是IntelliJ的忠實擁護者，并試圖充分利用它為Java提供的工具。
那時，我們的眼光已經超越了Java。有一些團隊對Scala感興趣，我們已經用它編寫了一些服務。但是，與Java代碼庫一起工作的復雜性、痛苦以及緩慢的構建時間，使得這種語言對我們大多數人都沒有吸引力。
當谷歌在2017年宣布Kotlin將成為Android開發(fā)的官方語言時，另一個與我們關系密切的團隊在他們的服務器端開發(fā)中評估了這種語言。最終，我們中的大多數人都嘗試了一下。
Kotlin對我們代碼庫的影響令我震驚。它讓人感覺更有成效，更安全，而且工具雖然沒有Java那么成熟，但也足以讓我們值得采用。
從感覺陳舊和冗長的語言中解脫出來，并發(fā)現(xiàn)哪些編碼風格非常適合Kotlin的特性，也是一件有趣的事情。與Java的出色互操作性意味著我們可以增量地依賴現(xiàn)有的生態(tài)系統(tǒng)和過渡系統(tǒng)，而不會對完成工作造成重大干擾。
很快，我就對Kotlin產生了興趣，共同創(chuàng)建了http4k，一個用于Kotlin HTTP應用的函數式工具包，并舉辦了“真實世界Kotlin開發(fā)研討會”，幫助其他團隊進行同樣的轉型。
最終，我已經轉到了其他崗位，但很幸運地看到了Kotlin在其他各種項目的服務器端的應用。而我也親身經歷了一些團隊強烈不愿意采用Kotlin的原因。
很奇怪的是，阻力并不總是來自于實際語言的優(yōu)劣。那么，為什么Java服務器端社區(qū)沒有更大程度地采用Kotlin呢?
我和我的同事遇到的一些原因如下：
我們沒有時間學習一種新語言
這就是我們在軟件項目中常見的“忙著砍柴，忙著磨斧頭”的變種。這通常是更深層次問題的征兆，如不斷增加的技術債務和一般的生產力問題。
健康的軟件項目總是需要相當數量的學習。而一個稱職的Java開發(fā)人員可以在幾個小時內掌握Kotlin的基礎知識，并在幾天內就會有合理的生產力。
當他們寫出更簡單的代碼和處理更少的問題時，因為新的語言而提高生產力，這是一項值得的投資。
每個版本的Java都在不斷完善
這是真的：Java正在變得更好。而且發(fā)布的速度也越來越快。另一方面，在處理空性這樣的簡單事情上，它仍然遠遠落后于Kotlin。
也許Java社區(qū)已經習慣了這種語言的發(fā)展速度。盡管如此，Kotlin仍然提供了一種方法，可以在他們的項目中利用這些特性中的許多(以及更多)。
作為Java開發(fā)人員，我們感到很高興
這種阻力是最棘手的。如果一個程序員把自己的職業(yè)身份綁在單一的編程語言上，那就沒什么辦法了。
一方面，如果Java開發(fā)人員不想賭上自己的事業(yè)，跳進一門新語言的未知領域，我可以理解?；蛘咚麄兿氤蔀橐幻L期的專家，這很公平。
另一方面，我還沒有看到Java開發(fā)人員因為使用Kotlin而“落后”。相反，這表明他們一直在尋找適合自己工作的最佳工具，這是一個積極的特質，至少對我?guī)椭衅傅娜藖碚f是這樣。
Kotlin是一門炒作高漲的語言，前途未卜
這是我們在2017年前后看到的一個常見的反對意見。在那一年，谷歌接受了Kotlin作為Android開發(fā)的一流語言，讓我們放心，大玩家們對這門語言的長久發(fā)展很感興趣。
今天，這種情況可能不太常見，因為像Spring和Micronaut這樣的流行框架似乎已經接受了新語言。
希望能給這門語言足夠的知名度，讓更多服務器端的人嘗試一下。
我正在使用Eclipse，但不想切換到IntelliJ
可以公平地說，Eclipse中的Kotlin體驗可能與JetBrains IDEA不符。
這是可以理解的，因為JetBrains的商業(yè)模式包括出售其開發(fā)人員工具。而且這種情況不太可能很快改變。
他們唯一的希望是Kotlin達到一個臨界質量，從而證明對Eclipse支持的進一步投資是合理的。在此之前，對于Kotlin開發(fā)人員來說，最好的開發(fā)體驗仍將停留在JetBrains產品上。
我的觀點是IntelliJ已經是一個更好的Java IDE了，所以它也值得一試。
Kotlin開發(fā)人員太昂貴了，很難獲得
很難評估這一點：在薪金網站上，可以得出結論，Kotlin的薪水總體上略高。
如果我們只想考慮服務器端開發(fā)人員，那就很難比較了。一般來說，那是Java領域工資最高的領域，Kotlin方面的數據還不夠多，無法比較。
坊間傳聞，我們在實踐中看到，資深的Java開發(fā)人員往往是最早采用Kotlin的人，這可能會給人一種Kotlin開發(fā)人員很貴的印象。
在招聘方面，我們還沒有看到吸引Kotlin開發(fā)人員的問題。我們明確工作需要使用新語言，并接受開發(fā)人員在工作中學習新語言。
這似乎能讓Java開發(fā)人員安心，吸引那些熱衷于學習新東西的人，這也是一個潛在的合適指標。
Kotlin太復雜了
Kotlin之所以能成為Scala等語言的一個引人注目的替代品，原因之一是它在開發(fā)者的易用性和高級特性之間取得了適當的平衡，使其與Java的可操作性和被流行框架采用成為可能。
在實踐中，這種異議往往與個人團隊的技能、風格、慣例有關。
初學者往往會像編寫Java一樣開始編寫Kotlin。隨著他們對這門語言越來越熟悉，他們很可能會把一些功能(如擴展和內聯(lián)函數)推得太遠，使得代碼庫對新手來說難以理解。
在團隊完全勝任新語言之前，我們強烈主張盡可能長時間地使用Boring Kotlin(TM)。最終，大多數團隊都會在挑選很酷的語言特性和讓整個團隊都能使用代碼之間找到平衡點。
在一個代碼庫中使用兩種語言令人困惑
那些沒有在實際項目中嘗試過Kotlin的人們普遍擔心。
在實踐中，只要團隊認同并注意到新的Kotlin代碼一開始需要與Java共存，在一個項目中使用兩種語言并不會帶來明顯的痛苦。
一個可以幫助的規(guī)則是："如果改動涉及到兩種語言，首先要把舊的代碼轉換成Kotlin"。
這樣一來，團隊就可以避免大刀闊斧的重寫，而逐步遷移需要增加新價值的地方。
如果有些代碼還保留在Java中，那也沒關系。很有可能是因為代碼還能用，沒有迫切的需要重構。
我們對Java感到更自在
在實踐中，可能是特定的上下文不需要新的語言。一切都很好;團隊以可接受的速度完成了事情，并且很好地掌握了Kotlin將幫助解決的問題。
然而，根據我們的經驗，這是例外而不是常規(guī)。更多的時候，這種阻力源于普遍缺乏時間或學習興趣，而不是缺乏需要改進的地方。
在嘗試真正的項目之前，也很難體會到Kotlin的好處，引入一門新的語言，即使是作為實驗，也會引起很多焦慮。
在這些情況下，我們推薦 "在職學習"(以編碼dojos、布朗包會議等形式)，以創(chuàng)造一個安全的環(huán)境，讓這種實驗能夠發(fā)生。
這種方法可以讓團隊評估他們對Java的使用和是否值得投資Kotlin。
我不知道Kotlin會帶來什么優(yōu)勢
有時，Java開發(fā)人員不知道語言的局限性，或者太習慣于這些局限性。其他時候，他們會拒絕任何讓他們質疑當前選擇的語言的選擇。
我們不細說，可以說Kotlin的簡潔和安全是它的主要優(yōu)勢。然而，有些人會說他們不認為Java的啰嗦有問題，寫出的代碼已經很安全了。
在嘗試之前很容易否定Kotlin，當面臨選擇時，少數人會繼續(xù)尋找理由不嘗試。
最后的想法
采用一種新的編程語言，尤其是在進行中的項目中，對大多數團隊來說都是一種挑戰(zhàn)。同樣重要的是要接受這樣的事實，即對變革的抵觸情緒與具體情況密切相關，它將來自項目需求和個人原因以及語言本身。
說了這么多，我還是鼓勵更多從事Java服務器端工作的開發(fā)者，如果有機會的話，可以嘗試一下Kotlin。如果沒有別的原因，它可能會突出代碼之外的其他改進領域。
原文地址:https://www.toutiao.com/i6946187492395581963/
