Java服務(wù)器端開發(fā)人員不采用Kotlin的原因是什么

這篇文章主要講解了“Java服務(wù)器端開發(fā)人員不采用Kotlin的原因是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Java服務(wù)器端開發(fā)人員不采用Kotlin的原因是什么”吧！

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

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

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

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

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

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

很快，我就對Kotlin產(chǎn)生了興趣，共同創(chuàng)建了http4k，一個(gè)用于Kotlin  HTTP應(yīng)用的函數(shù)式工具包，并舉辦了“真實(shí)世界Kotlin開發(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的原因。

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

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

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

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

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

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

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

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

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

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

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

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

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

Kotlin是一門炒作高漲的語言，前途未卜

這是我們在2017年前后看到的一個(gè)常見的反對意見。在那一年，谷歌接受了Kotlin作為Android開發(fā)的一流語言，讓我們放心，大玩家們對這門語言的長久發(fā)展很感興趣。

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

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

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

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

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

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

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

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

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

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

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

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

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

Kotlin太復(fù)雜了

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

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

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

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

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

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

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

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

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

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

我們對Java感到更自在

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

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

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

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

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

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

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

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

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

感謝各位的閱讀，以上就是“Java服務(wù)器端開發(fā)人員不采用Kotlin的原因是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Java服務(wù)器端開發(fā)人員不采用Kotlin的原因是什么這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！