為何是Kotlin:

很多人對Kotlin沒有一個正確的定位,可能大家第一反應(yīng)是拿它去和scala,groovy比較，從語法的角度而言,kotlin豐富且嚴謹?shù)角〉胶锰幍恼Z法糖,表達能力強但不啰嗦,極少的代碼冗余。

但老實講能做到這些的語言也不算少，單看語法，事實上Kotlin比scala還是要略差一籌的，他們都是非常優(yōu)秀的jvm語言,總體來說是難分伯仲,Kotlin也沒辦法將他們甩出一個身位。

但我必須得說,絕大部分情況下(指常規(guī)開發(fā)),如果你選擇Kotlin作為你的第二jvm語言,比用scala,groovy等，開發(fā)工程中的收益要多的多的多...成本亦低的多的多的多(注意我不是單單在說語言層面了)

首先，最重要也是讓kotlin與其他jvm語言有本質(zhì)不同的地方在于：無縫和java程序的銜接以及極低的交互成本。

老項目想嘗新?在maven或gradle里面加個配置，就能開寫kotlin了.

不敢直接用?先用來寫UT啊,UT寫順了，你自然會忍不住想繼續(xù)寫。

已有java代碼怎么辦?直接用啊，封裝都不用，兩者可以直接調(diào)用，智能提示也都在，反過來kotlin寫的庫java同樣能用。

kotlin的一些典型特征:

靜態(tài)強類型

這個不多說，java，C#，kotlin都是典型，稍微上點規(guī)模的項目，都應(yīng)該用靜態(tài)強類型來打底子。TypeScript越來越火也可見一般。

當然我不是說靜態(tài)就優(yōu)于動態(tài)，這是看場景的，比如需求相對復雜和穩(wěn)定的后端和隨業(yè)務(wù)迅速迭代的前端，他們的技術(shù)訴求肯定就不一樣。

比如做gateway，我就覺得動態(tài)類型的語言更適合，參考阿里的node.js使用場景。

學習成本

其實大家回憶下學習語言的過程,是花在語法上的時間多,還是花在熟悉標準庫上的時間多?

而kotlin則完全沒有后者的成本,time還是用的joda,http還是Apache的HttpClient,或者OkHTTP，

也會糾結(jié)netty，tomcat，akka 的方案選型，同樣需要注意集合類的時間復雜度和線程安全情況。

可以說在熟悉java生態(tài)的前提下學習Kotlin，成本是非常低的。

其實我給人安利時候，一般給C#的人說Kotlin，就是“jvm屆的C#”

給Java的人說：“你別把它當新語言，你就把他當Java9”，當然9現(xiàn)在已經(jīng)發(fā)布了，我可以換成10了，哈哈。

學習新語言總是會給人帶來一些壓力，但也要注意語言和語言之間的學習成本的不同，

我曾開玩笑說：我學習scala(入門)花的功夫，足夠我學會js，php，python這三門語言了。

而Kotlin的低成本高收益，才是我對它如此推崇的最大原因。

生態(tài)支持

最后,也是最重要的優(yōu)勢:jetBrains爸爸全方位無死角超貼心的配套支持

(畫外音:用過Resharper,IDEA,WebStorm,PyChrome的朋友,讓我看到你們的雙手!!)

熟悉jetBrain的朋友,應(yīng)該能夠感覺到,這是一家非常有特色和魅力的公司,其在ide和pl工程領(lǐng)域的積累,大家應(yīng)該也心里有數(shù).

j系ide都有一個特點,就是對開發(fā)者極其友好,

基于語法(AST?)而非文本的代碼分析,帶來的超高的智能提示準確率和極度便利的重構(gòu),

對可能的異常代碼的警告和解決方案的提示.jetBrains總是傾向于讓開發(fā)者寫出嚴謹又簡潔且魯棒的代碼。

幸運的是,Kotlin也繼承了爸爸的這些特質(zhì),不僅僅是語法的嚴謹,還體現(xiàn)在了開發(fā)過程中。

比如maven配置,java交互,nullable的注解提示,idea配套插件.

而且Kotlin是他們內(nèi)部很早就立項的語言，他家的各路ide都是用Kotlin寫的。

各種插件個ide的支持，基本可以和語言版本同步迭代。

說了這么多文字,且廢話占多數(shù),想必大家也有點煩了,那我下面就以java和Kotlin的比較為切入點,介紹一些Kotlin的特點吧。

其實就是過一遍Kotlin/kotlin-koans,建議有興趣的可以clone個玩玩。

val 定義的變量不可變

var 同C#,val和var都是隱式強類型推斷,

val的作用在于,我前面定義一個orderState,即表示,這個變量就只做取值用途,你別再拿來干別的事情了,避免了一值多用的bad small.

默認參數(shù),及參數(shù)名傳參:

減少無意義多態(tài)的使用,但又比js的一值多用直觀的多.

labmda寫法改進

必須在一個花括號中,如果以lambda為參數(shù),可省略(),看起來很舒服

如果只有一個參數(shù),則可以省略聲明,用it代替,(同scala的 _ )

scala的一個參數(shù)對應(yīng)的_只能出現(xiàn)一次,第二個_代表第二個參數(shù),更簡潔的寫法但帶來更模糊的語義,孰優(yōu)孰劣不談,但兩者的風格差異在這個細節(jié)中可見一斑.

nullable

Kotlin對null pointer 問題非常敏感,任何可能的npr都需要顯示的處理,如果不處理,nullable會一直往后傳染并給出一個警告,

這時候你要么用!!表示我tm確定這里肯定不為null,要么用?:表示如果為空,則表達式的值為后面提供的缺省值. 這個設(shè)計基本和C#那邊的一樣

tems是訂單詳情的集合,詳情包含ActualWeight,但未發(fā)生實提則為null,如果是傳統(tǒng)寫法,需要先判斷find出來的是否是null,再判斷這個find是否有實提,如果有則返回實提,沒有則返回double 0(lambda可省略return)

大家可以體會下這省了多少工夫?

擴展方法,

這是我覺得所有靜態(tài)語言都應(yīng)該提供的特性,原理非常簡單,但帶來的寫法上的優(yōu)化非常有價值

Kotlin和C#擴展方法原理大致類似，就是this作為第一個參數(shù)傳給靜態(tài)方法的一個語法糖，但Kotlin不要求強制定義在一個靜態(tài)方法中

表示所有的string實例,在lastChar的可訪問范圍內(nèi),都多了一個成員函數(shù),其實就是

static StringHelper.lastChar(str:String)

的變種,在不支持em的java看來,就長剛才這個樣子,用起來就是如下形式:

H3.em3(H2.em2(Helper1.em1(what)))

low爆了是吧? 下面是我封裝的一個操作poi的代碼

next是移動到下一單元格,設(shè)置樣式是復制第一行的樣式,其實還可以封裝,為了顯示表達出我的操作意圖,這里就留著了.

說到這里就差不多了,再說也就是抄襲koans,也沒啥大的意思了,最后扯點其他的作收尾吧.

談一談我對語法糖的看法:

我個人對語法糖的評價是非常高的,也許這個糖的原理并不復雜,比如我之前提到的擴展方法,但我們認識它的原理是遠遠不夠的,還得理解,為什么要有這玩意.

H3.em3(H2.em2(Helper1.em1(what))) VS what.em1().em2().em3()

上面后者省略了import H1 H2 H3的過程,綜合起來工作量也沒差太多

但真的就僅僅是寫法和視覺上的優(yōu)化嗎?其實遠遠不止.

前者是,XXHelper里面有個方法,可以操作what這個類型并做一些事情,

后者是,what既然有這樣的特質(zhì),那么它就應(yīng)該擁有某樣的能力

前者是思維先找到Helper,再找到具體方法,

后者是what自然而然的提示出,what就有這樣的能力(ide的智能提示),我敲下what+ . 后,它的能力就展示在我面前了,而不需要我還去翻箱倒柜的找helper方法.

談?wù)劶みM技術(shù)的風險和收益,與不同階層人員關(guān)注點的不同.

我最早推進Kotlin的時候,最大的阻力就是來自公司的架構(gòu)師團隊,他們的關(guān)注點是:

Kotlin相比java,能提高性能嗎?(不能,Kotlin的性能與java極度接近但略小與java)

Kotlin解決了什么java并不能解決的問題嗎?(沒有,Kotlin只是讓你更快更好的寫java代碼)

Kotlin能減少項目bug,提高項目穩(wěn)定性嗎?(某種程度上來說有一定幫助,但更多是看人,這理由也不夠強力)

那時候我只是個開發(fā) leader,這種層面肯定是沒有太大的決策權(quán)的,他們的想法我也理解,公司幾百號開發(fā),提高一點點效率,相比引入新技術(shù)棧的風險,肯定是穩(wěn)定壓倒一切啦.

后面在我的爭取下,我在一個簡單項目上少量使用kotlin作為試點,后來一些原因我離開了這個公司,去小公司當技術(shù)合伙人去了,現(xiàn)在那段kotlin代碼應(yīng)該還跑在公司的tomcat上面,其他人不去翻代碼,他們也不會知道這是用kotlin寫的吧?