這篇文章將為大家詳細(xì)講解有關(guān)Kotlin與Java主客觀對比的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

創(chuàng)新互聯(lián)致力于成都網(wǎng)站制作、網(wǎng)站設(shè)計、外貿(mào)網(wǎng)站建設(shè),成都網(wǎng)站設(shè)計,集團(tuán)網(wǎng)站建設(shè)等服務(wù)標(biāo)準(zhǔn)化，推過標(biāo)準(zhǔn)化降低中小企業(yè)的建站的成本，并持續(xù)提升建站的定制化服務(wù)水平進(jìn)行質(zhì)量交付，讓企業(yè)網(wǎng)站從市場競爭中脫穎而出。 選擇創(chuàng)新互聯(lián)，就選擇了安全、穩(wěn)定、美觀的網(wǎng)站建設(shè)服務(wù)！

Kotlin

Kotlin是一門相對比較新的JVM語言，JetBrains自2011年以來一直在積極地開發(fā)。

多年來，該語言在Android社區(qū)受到的關(guān)注度越來越高，并在Google IO 2017大會之后成為Android開發(fā)領(lǐng)域最熱門的話題。這次大會宣布，Android正式支持Kotlin。

遺憾的是，雖然已經(jīng)有許多關(guān)于Kotlin的文章，但并沒有多少客觀信息，許多開發(fā)人員仍然在苦思冥想，遷移到Kotlin是否是一條正確的道路。

在本文的剩余部分，我將嘗試提供一個在將Kotlin作為Java的替代項進(jìn)行評估時需要考慮的更完善的事項清單。

Kotlin與Java的主觀比較

“Kotlin比Java好”，“Kotlin可讀性比Java強(qiáng)”，“Kotlin開發(fā)速度比Java快”，類似這樣的陳述缺少相關(guān)準(zhǔn)確數(shù)據(jù)的支持，所以都?xì)w為主觀看法一類。

主觀看法是個體開發(fā)人員在對與Kotlin或Java相關(guān)的主題作出一個或多個主觀判斷時形成。

開發(fā)人員的主觀判斷存在如下問題：

沒有與主觀判斷相關(guān)聯(lián)的量化指標(biāo)。
主觀判斷存在很大的偏見。
主觀判斷的偏見在開發(fā)人員之間存在很大的差異。
由于沒有與主觀判斷相關(guān)聯(lián)的量化指標(biāo)，建立在這些判斷基礎(chǔ)上的觀點(diǎn)只是反映出了開發(fā)人員之前就有的偏見。不同的開發(fā)人員可能有著截然不同的偏見，因此，有開發(fā)人員認(rèn)為Kotlin是不錯（或糟糕）的Java替代者并不意味著其他開發(fā)人員也這么認(rèn)為。

而且，由于沒有客觀指標(biāo)，主觀分歧就無法客觀地消除，這經(jīng)常會導(dǎo)致“口水戰(zhàn)”。

主觀判斷的謬誤

為了說明主觀判斷可能導(dǎo)致的誤解，讓我們仔細(xì)審視一個非常常見的主觀看法：

Kotlin可讀性比Java強(qiáng)

——Web上無數(shù)的文章

理論上講，可以設(shè)法設(shè)計一個度量Kotlin和Java之間可讀性差異的實驗，但據(jù)我所知，沒有任何人真正地開展這樣一個實驗。因此，截至目前，這個看法沒有任何數(shù)據(jù)支撐。

Kotlin的語法是許多開發(fā)人員稱贊其可讀性的一個原因。他們的邏輯如下：

Kotlin有更好的語法，因此它的可讀性更強(qiáng)

——Web上無數(shù)的文章

在這句話中，“更好的語法”又是一個主觀判斷，本身就值得商榷，但為了避免爭論，我們假設(shè)Kotlin的語法確實更好。但是，這就能說明Kotlin的可讀性更強(qiáng)嗎？

為了觀察語法對可讀性的影響，請閱讀下這段“文本”：

開始的時候，這段“文本”很難理解，但慢慢地，讀起來會越來越容易。如果你再讀個兩三遍，那么你根本就不會再注意它是由非標(biāo)準(zhǔn)的字母組成的。準(zhǔn)確地說，字母的替換不是句法變化，但這確實可以說明，對于熟練的讀者而言，外觀很少會成為可讀性的障礙。

我們也可以把這個例子擴(kuò)展到自然語言。我了解三門截然不同的語言。雖然它們之間差別很大，但我發(fā)現(xiàn)，當(dāng)我不理解文本中使用的單詞時，閱讀任何一種語言的文本都非常困難。一旦我認(rèn)識構(gòu)成文本的單詞并熟悉上下文——無論它使用了哪一種語言，我讀起來都不困難。

因此，對我而言，語言的選擇并不會影響可讀性，只要理解內(nèi)容和上下文就可以了。

編程語言同樣如此。

當(dāng)我們開始使用一門新語言，我們會有一段時間很難理解源代碼，需要認(rèn)真領(lǐng)會每個句法結(jié)構(gòu)。但是，隨著我們閱讀和編寫特定語言的代碼越來越多，我們逐漸就熟悉了那門語言的語法，到某個時候，我們就不會再注意句法結(jié)構(gòu)了。

我自己在多門語言上有過這種體驗：Verilog、Bash、Perl、Tcl、Lisp、Java。

根據(jù)我使用上述語言的經(jīng)驗，我可以告訴你：如果一個人適應(yīng)了Lisp的代碼，并且不會再注意到小括號，那么跟Java比起來，Kotlin的語法完全不能對可讀性產(chǎn)生不可忽視的影響，即使它“更好”。

既然我們在討論這個話題，我就分享下自己對于影響源代碼可讀性因素的主觀判斷。

在讀過其他開發(fā)人員使用許多語言編寫的代碼后（上面只羅列了我在某個階段精通的語言；我用過的所有語言比這個多），我得出如下結(jié)論：如果開發(fā)人員使用某一門語言可以編寫出可讀性和可理解性都很好的代碼，那么他們通常也可以使用其他語言編寫出可讀性和可理解性都很好的代碼。

因此，我根據(jù)自己的經(jīng)驗作出的主觀判斷是，源代碼的可讀性和選擇的語言無關(guān)，那取決于代碼編寫者的技能和讀者的技能（編寫者的技能更重要）。

如果你仍然認(rèn)為主觀看法具有代表性，那么至少閱讀并思考下Robert “Uncle Bob” Martin在這篇博文中的觀點(diǎn)。

Kotlin與Java的客觀比較

與主觀比較相反，客觀比較使用量化指標(biāo)來度量或評估Kotlin比Java有優(yōu)勢的地方。

用一套標(biāo)準(zhǔn)客觀地證明一門編程語言是否強(qiáng)過另一門，這種想法非常有吸引力，但是有個問題：據(jù)我所知，沒有與編程語言相關(guān)的通用客觀指標(biāo)。

考慮到我們無法進(jìn)行精確的直接比較，那我們能否客觀地比較Kotlin和Java呢？能！我們?nèi)匀荒茉u估從Java切換到Kotlin所帶來的積極和消息影響的程度，然后比較結(jié)果，并討論它們的影響。

為了評估Kotlin所能帶來的最好結(jié)果，我們將做如下假設(shè)：

開發(fā)人員可以立即切換到Kotlin；

切換到Kotlin后，開發(fā)人員不會損失任何技能（例如，有兩年Java開發(fā)經(jīng)驗的開發(fā)人員可以神奇地獲得兩年的Kotlin開發(fā)經(jīng)驗）；
Kotlin和Java一樣穩(wěn)定；
Kotlin工具和Java工具一樣成熟。

事實上，上述假設(shè)沒有一個是合理的，但在開始的時候，有一個理想化的設(shè)定便于說明。然后，我們會拋開這些假設(shè)，討論真實世界的效應(yīng)所帶來的影響。

Kotlin最佳結(jié)果估計

遵循Steve McConnell在Code Complete一書中提出的模式，我們可以將軟件構(gòu)建活動分解成三個子活動：詳細(xì)設(shè)計、編碼與調(diào)試、開發(fā)測試。

Kotlin對于詳細(xì)設(shè)計子活動沒什么影響（這項活動通常獨(dú)立于選用的特定的面向?qū)ο缶幊陶Z言），因此，在這一部分，Kotlin和Java需要付出同樣的努力。

據(jù)我所知，對于開發(fā)測試子活動，Kotlin也沒有提出什么革命性的東西。因此，開發(fā)測試需要付出的努力也一樣。

就剩編碼與調(diào)試子活動了。

如果我們用Kotlin替換Java，那么我在編碼與調(diào)試活動中可以節(jié)省多少工作量？這個問題很難回答，不同程序員之間這一數(shù)值會有很大差異（有些程序員使用Java更高效）。不過，既然我們在評估最好的情況，我們不妨假設(shè)從Java切換到Kotlin可以將開發(fā)人員在編碼與調(diào)試階段的生產(chǎn)力平均提高10%。

10%的生產(chǎn)力提升是一個不現(xiàn)實到令人吃驚的數(shù)值。即使我們在文本編輯器中手工輸入所有代碼，那也是不現(xiàn)實的。考慮到現(xiàn)如今IDE的功能，這一數(shù)值更是不現(xiàn)實。考慮到有些開發(fā)人員使用Java更高效，這個數(shù)值就毫無道理了。

我不介意使用這樣一個既不現(xiàn)實又對Kotlin評估有利的數(shù)值，因為我知道，不管它對評估結(jié)果產(chǎn)生了怎樣不切實際的積極影響，一旦我們拋開其中部分“理想的假設(shè)”，由此帶來的負(fù)面影響會抵消掉那些積極影響。

那么，在編碼與調(diào)試方面提升了10%——我們把產(chǎn)品交付給客戶的速度快了多少？

下面這張圖片來自Code Complete一書，展示了軟件項目的各種活動所占的比例：

圖 小項目以構(gòu)建活動為主。大點(diǎn)的項目需要更多架構(gòu)、集成和系統(tǒng)測試工作來保證項目成功。這張圖沒有顯示需求，因為和其它活動不一樣，需求工作不是直接的程序功能。（Albrecht 1979; Glass 1982; Boehm, Gray, and Seewaldt 1984; Boddie 1987; Card 1987; McGarry, Waligora, and McDermott 1989; Brooks 1995; Jones 1998; Jones 2000; Boehm et al. 2000）
Code Complete，第二版

根據(jù)來自Code Complete的這張圖片，在一個較大的軟件項目中（多于10K行），編碼和調(diào)試只占項目總工作量的不足20%。

因此，在一個較大的軟件項目中，我們所假設(shè)的編碼和調(diào)試效率提升10%，只能將完成項目所需的總工作量縮減2%。

例如，一個需要5人年才可以完成的項目（這是相對比較大的Android項目），總工作量的2%為：

5人-年 * 12 * 4 * 5 * 0.02 = 24（人-天）
如果我們真得能夠把項目工作量減少24人-天，這會是一個從Java切換到Kotlin的很好的理由。然而，我們應(yīng)該還記得，上述積極評估是在理想情況下得出的，其基礎(chǔ)是不切實際的假設(shè)。

在真實世界里，切換到另外一門編程語言會產(chǎn)生不可避免的影響，我們將評估這種影響，并與上述理想化評估作個比較。

開發(fā)人員準(zhǔn)備

為了評估最好的情況，我們假設(shè)開發(fā)人員可以立即從Java切換到Kotlin。

實際上，雖然Kotlin和Java非常類似，但開發(fā)人員仍然需要花一些時間來學(xué)習(xí)，然后再花一些時間來調(diào)整開發(fā)實踐和工具。準(zhǔn)備時間因人而異：有些開發(fā)人員可以三四天完成切換，其他人則需要10天甚至更多的時間。

讓我們樂觀一點(diǎn)，平均每個開發(fā)人員只要5天就可以從Java切換到Kotlin。

一個需要5人年才能完成的項目會有3到5名開發(fā)人員（最好的情況下）。平均每個開發(fā)人員的切換時間為5天，這樣，一個項目總計就需要15到25個人天的切換時間。

切換到Kotlin所節(jié)省的工作量（樂觀估計）與切換所需的總工作量似乎差不多。

開發(fā)人員技能損失

使用一門特定的編程語言高效工作的能力是一項技能。

我們已經(jīng)討論了這項技能的其中一個方面（代碼可讀性），但還有許多其他方面。當(dāng)從一門語言切換到另一門時，與舊編程語言相關(guān)的部分技能可以運(yùn)用到新語言上，但該技能的其他部分會損失掉。

為了評估編程語言技能損失對項目工作量的影響，我們將使用源自Cocomo2評估模型的“語言與工具體驗”因子：

語言與工具經(jīng)驗（LTEX）

該指標(biāo)用于衡量開發(fā)軟件系統(tǒng)或子系統(tǒng)的項目團(tuán)隊使用編程語言和軟件工具的經(jīng)驗。軟件開發(fā)包括借助工具完成需求、表現(xiàn)形式設(shè)計與分析、配置管理、文檔提取、庫管理、程序樣式與格式化、一致性檢查、計劃與控制等等。除了項目編程語言經(jīng)驗外，項目支持工具集的經(jīng)驗也會影響開發(fā)工作。經(jīng)驗低于2個月會獲得一個很低的評級，有6個月或多年的經(jīng)驗則會獲得一個很高的評級，見下表：

我不知道這是什么樣的衰退，有多少項目受到了影響，但我的大腦自動將“重大性能衰退”這個搭配翻譯成了“浪費(fèi)了許多小時的開發(fā)時間。”

此外，如果你讀一遍發(fā)布說明的評論，你就會注意到，許多人遇到了遷移問題。在1.1.2版本的評論里，甚至有人指出，這個“補(bǔ)丁”發(fā)布引入了破壞性（向后不兼容）的修改。

相比之下，如果你讀一遍Oracle JDK8的發(fā)布說明，你就會發(fā)現(xiàn)，它比較穩(wěn)定。大多數(shù)修改都是安全改進(jìn)方面的。

因此，與Java相比，Kotlin是一門不穩(wěn)定且不成熟的語言——遷移到Kotlin會對項目產(chǎn)生怎樣的影響？為了回答這個問題，我將使用來自Cocomo 2評估模型的“平臺波動性”工作因子：

平臺波動性（PVOL）

這里使用“平臺”一詞指代軟件產(chǎn)品執(zhí)行任務(wù)時調(diào)用的復(fù)雜硬件和軟件（OS、DBMS等）。如果開發(fā)的軟件是一個操作系統(tǒng)，那么平臺就是計算機(jī)硬件。如果開發(fā)的是數(shù)據(jù)庫管理系統(tǒng)，那么平臺就是硬件和操作系統(tǒng)。如果開發(fā)的是網(wǎng)絡(luò)文本瀏覽器，那么平臺就是網(wǎng)絡(luò)、計算機(jī)硬件、操作系統(tǒng)和分布式信息庫。平臺包括支撐軟件系統(tǒng)開發(fā)所需的編譯器或裝配器。如下表所示，如果平臺每12個月才有一次重大變更，則評級就會很低，如果每2周有一次重大變更，則評級就會很高：

Cocomo2模型定義手冊

你可能已經(jīng)注意到，編程語言并沒有直接出現(xiàn)在該工作因子的描述里，但出現(xiàn)了編譯器和裝配器。在我看來，這段描述沒有顯式包含編程語言，是因為得出Cocomo2模型的所有項目都使用了穩(wěn)定的語言。

由于編譯器和裝配器屬于這個工作因子，所以我們也可以推斷出編程語言及相關(guān)工具。

根據(jù)平臺波動性的這種評級范圍，Java的評級應(yīng)該是“verylow”，而Kotlin的評級應(yīng)該是“l(fā)ow”或更高。Kotlin的評級可能會更高，因為它內(nèi)部依賴于其它工具，增加了出現(xiàn)兼容性問題的風(fēng)險。

由于“verylow”沒有提供工作因子，所以我們需要估計。

看下該因子從“veryhigh”到“l(fā)ow”的評分遞減規(guī)律，我認(rèn)為，我們可以放心的假設(shè)，“verylow”的評分不高于0.82。

基于這些假設(shè)（有利于Kotlin），如果一個項目需要5人年的額定工作量，那么使用Kotlin，工作量就變成了1044人天，而使用Java的總工作量是984人天。

選擇使用Kotlin而不是Java實現(xiàn)這樣一個項目會使總工作量增加60人天。

語言和工具不穩(wěn)定所導(dǎo)致的額外工作是切換到Kotlin所縮減的工作的2倍多。

綜合所有因素

我當(dāng)成例子來討論的項目需要5人年的額定工作量。

根據(jù)上述評估，如果該項目由平均具備1年Java開發(fā)經(jīng)驗的開發(fā)人員使用Java實現(xiàn)，則總工作量為：

5人-年*LTEX(Java)*PVOL(Java)=984(人-天)

如果同樣的項目由幾乎沒有Kotlin開發(fā)經(jīng)驗的開發(fā)人員使用Kotlin實現(xiàn)，則總工作量為：

5人-年*LTEX(Kotlin)*PVOL(Kotlin)*0.98+T_ramp_up=1115+5*N_developers(人-天)

據(jù)估計，選擇Kotlin替換Java所導(dǎo)致的額外工作量為131+5*N_developers(人-天)。

評估注意事項

在評估討論的過程中，我們得出了與Kotlin和Java相關(guān)的、便利的工作量單點(diǎn)值。

但實際上，單點(diǎn)值根本不是估計——它們只是猜測。真正的估計必須有一個相關(guān)聯(lián)的不確定性。換句話說，估計表示可能性的范圍，而不是單點(diǎn)值。

我們最終使用單點(diǎn)值代替了范圍，那是因為我從估算范圍里選擇了最有利于Kotlin的值，將所有的估計都轉(zhuǎn)換成了單點(diǎn)值。

例如，當(dāng)討論Kotlin對編碼與調(diào)試活動的影響時，我從估計出的可能性范圍[-5%，10%]中選擇了最大的生產(chǎn)力提升值10%。在其他情況下，當(dāng)我們討論開發(fā)人員切換到Kotlin的平均時間時，我從估計的可能性范圍[5天，21天]中選擇了最小的5天。

此外，我們使用了Cocomo2估計模型專用的工作因子。這些因子并不是放之四海而皆準(zhǔn)的真理，在最一般的情況下，應(yīng)該也有相關(guān)聯(lián)的不確定性。我賦給Kotlin的評級高于我實際上認(rèn)為它應(yīng)得的評級，我希望通過這種方式消除這種不確定性。

不用說，我們獲得的單點(diǎn)值并不是百分百正確。為了得出更完整的估計，我們可以利用真正的估計進(jìn)行MonteCarlo仿真。通過這項技術(shù)，我們可以觀察可能結(jié)果的分布，弄清楚哪種結(jié)果最可能出現(xiàn)。

請記住，由于我們將估計壓縮成了對Kotlin而言最為有利的單點(diǎn)值，所以其他可能的結(jié)果會顯示出更大的Kotlin切換開銷。因此，在所有可能的結(jié)果中，我們在上文描述的單點(diǎn)值是最有利于Kotlin的。

關(guān)于“Kotlin與Java主客觀對比的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。

分享標(biāo)題：Kotlin與Java主客觀對比的示例分析
URL網(wǎng)址：http://www.chinadenli.net/article38/gicgsp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、關(guān)鍵詞優(yōu)化、面包屑導(dǎo)航、網(wǎng)站改版、品牌網(wǎng)站建設(shè)、小程序開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)