Kotlin

Kotlin 是一門(mén)相對(duì)比較新的 JVM 語(yǔ)言，JetBrains 自 2011 年以來(lái)一直在積極地開(kāi)發(fā)。

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

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

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

Kotlin 與 Java 的主觀比較

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

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

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

• 沒(méi)有與主觀判斷相關(guān)聯(lián)的量化指標(biāo)。
• 主觀判斷存在很大的偏見(jiàn)。
• 主觀判斷的偏見(jiàn)在開(kāi)發(fā)人員之間存在很大的差異。

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

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

主觀判斷的謬誤

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

• Kotlin 可讀性比 Java 強(qiáng)
• ——Web 上無(wú)數(shù)的文章

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

Kotlin 的語(yǔ)法是許多開(kāi)發(fā)人員稱(chēng)贊其可讀性的一個(gè)原因。他們的邏輯如下：

• Kotlin 有更好的語(yǔ)法，因此它的可讀性更強(qiáng)
• ——Web 上無(wú)數(shù)的文章

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

為了觀察語(yǔ)法對(duì)可讀性的影響，請(qǐng)閱讀下這段“文本”：

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

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

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

編程語(yǔ)言同樣如此。

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

我自己在多門(mén)語(yǔ)言上有過(guò)這種體驗(yàn)：Verilog、Bash、Perl、Tcl、Lisp、Java。

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

既然我們?cè)谟懻撨@個(gè)話(huà)題，我就分享下自己對(duì)于影響源代碼可讀性因素的主觀判斷。

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

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

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

Kotlin 與 Java 的客觀比較

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

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

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

為了評(píng)估 Kotlin 所能帶來(lái)的***結(jié)果，我們將做如下假設(shè)：

1. 開(kāi)發(fā)人員可以立即切換到 Kotlin;
2. 切換到 Kotlin 后，開(kāi)發(fā)人員不會(huì)損失任何技能(例如，有兩年 Java 開(kāi)發(fā)經(jīng)驗(yàn)的開(kāi)發(fā)人員可以神奇地獲得兩年的 Kotlin 開(kāi)發(fā)經(jīng)驗(yàn));
3. Kotlin 和 Java 一樣穩(wěn)定;
4. Kotlin 工具和 Java 工具一樣成熟。

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

Kotlin ***結(jié)果估計(jì)

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

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

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

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

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

10%的生產(chǎn)力提升是一個(gè)不現(xiàn)實(shí)到令人吃驚的數(shù)值。即使我們?cè)谖谋揪庉嬈髦惺止ぽ斎胨写a，那也是不現(xiàn)實(shí)的。考慮到現(xiàn)如今 IDE 的功能，這一數(shù)值更是不現(xiàn)實(shí)?？紤]到有些開(kāi)發(fā)人員使用 Java 更高效，這個(gè)數(shù)值就毫無(wú)道理了。

我不介意使用這樣一個(gè)既不現(xiàn)實(shí)又對(duì) Kotlin 評(píng)估有利的數(shù)值，因?yàn)槲抑?，不管它?duì)評(píng)估結(jié)果產(chǎn)生了怎樣不切實(shí)際的積極影響，一旦我們拋開(kāi)其中部分“理想的假設(shè)”，由此帶來(lái)的負(fù)面影響會(huì)抵消掉那些積極影響。

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

下面這張圖片來(lái)自 Code Complete 一書(shū)，展示了軟件項(xiàng)目的各種活動(dòng)所占的比例：

圖小項(xiàng)目以構(gòu)建活動(dòng)為主。大點(diǎn)的項(xiàng)目需要更多架構(gòu)、集成和系統(tǒng)測(cè)試工作來(lái)保證項(xiàng)目成功。這張圖沒(méi)有顯示需求，因?yàn)楹推渌顒?dò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ù)來(lái)自 Code Complete 的這張圖片，在一個(gè)較大的軟件項(xiàng)目中(多于 10K 行)，編碼和調(diào)試只占項(xiàng)目總工作量的不足 20%。

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

例如，一個(gè)需要 5 人年才可以完成的項(xiàng)目(這是相對(duì)比較大的 Android 項(xiàng)目)，總工作量的 2%為：

• 5 人-年 * 12 * 4 * 5 * 0.02 = 24(人-天)

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

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

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

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

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

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

一個(gè)需要 5 人年才能完成的項(xiàng)目會(huì)有 3 到 5 名開(kāi)發(fā)人員(***的情況下)。平均每個(gè)開(kāi)發(fā)人員的切換時(shí)間為 5 天，這樣，一個(gè)項(xiàng)目總計(jì)就需要 15 到 25 個(gè)人天的切換時(shí)間。

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

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

使用一門(mén)特定的編程語(yǔ)言高效工作的能力是一項(xiàng)技能。

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

為了評(píng)估編程語(yǔ)言技能損失對(duì)項(xiàng)目工作量的影響，我們將使用源自 Cocomo2 評(píng)估模型的“語(yǔ)言與工具體驗(yàn)”因子：

語(yǔ)言與工具經(jīng)驗(yàn)(LTEX)

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

Cocomo 2 模型定義手冊(cè)

例如，假設(shè)我們有一個(gè) Java 開(kāi)發(fā)團(tuán)隊(duì)，團(tuán)隊(duì)成員平均有一年的經(jīng)驗(yàn)，我們想遷移到 Kotlin。

由于 Kotlin 和 Java 非常像，與許多 Java 工具兼容。我們可以樂(lè)觀地假設(shè)，在經(jīng)過(guò)初步的準(zhǔn)備后，開(kāi)發(fā)人員就可以歸為有 6 個(gè)月開(kāi)發(fā)經(jīng)驗(yàn)這一類(lèi)(而不是低于 2 個(gè)月)。根據(jù)這個(gè)假設(shè)，為了評(píng)估技能損失所導(dǎo)致的額外工作，項(xiàng)目的額定工作總量應(yīng)該乘以 1.09。

一個(gè)需要 5 人年完成的項(xiàng)目，配備了平均具有 1 年 Java 經(jīng)驗(yàn)的開(kāi)發(fā)人員，切換到 Kotlin 所導(dǎo)致的額外工作達(dá)到了令人咂舌的 108 人天。

技能損失所導(dǎo)致的額外工作是切換到 Kotlin 所縮減的工作的四倍。

語(yǔ)言和工具的穩(wěn)定性和成熟度

有個(gè)普遍的說(shuō)法，就是 Kotlin 是一門(mén)生產(chǎn)就緒的語(yǔ)言。這種說(shuō)法也許是有道理的，因?yàn)?Kotlin 已經(jīng)用在了若干項(xiàng)目里。

不過(guò)，與 Java 相比，Kotlin 是一門(mén)并不穩(wěn)定的年輕語(yǔ)言。

有些開(kāi)發(fā)人員認(rèn)為，Kotlin 的不穩(wěn)定性是個(gè)優(yōu)勢(shì)——語(yǔ)言在演進(jìn)，可以更快地提供新特性，更快地改進(jìn)。在我看來(lái)，他們對(duì)于這件事的看法過(guò)于簡(jiǎn)單。

下面是 Kotlin 1.1.4 發(fā)布說(shuō)明里的***句話(huà)(寫(xiě)這篇文章時(shí)的***版本)：

• 修復(fù) IntelliJ IDEA 的一項(xiàng)重大性能衰退
• ——Kotlin 1.1.4 發(fā)布說(shuō)明

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

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

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

因此，與 Java 相比，Kotlin 是一門(mén)不穩(wěn)定且不成熟的語(yǔ)言——遷移到 Kotlin 會(huì)對(duì)項(xiàng)目產(chǎn)生怎樣的影響?為了回答這個(gè)問(wèn)題，我將使用來(lái)自 Cocomo 2 評(píng)估模型的“平臺(tái)波動(dòng)性”工作因子：

平臺(tái)波動(dòng)性(PVOL)

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

Cocomo 2 模型定義手冊(cè)

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

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

根據(jù)平臺(tái)波動(dòng)性的這種評(píng)級(jí)范圍，Java 的評(píng)級(jí)應(yīng)該是“very low”，而 Kotlin 的評(píng)級(jí)應(yīng)該是“low”或更高。Kotlin 的評(píng)級(jí)可能會(huì)更高，因?yàn)樗鼉?nèi)部依賴(lài)于其它工具，增加了出現(xiàn)兼容性問(wèn)題的風(fēng)險(xiǎn)。

由于“very low”沒(méi)有提供工作因子，所以我們需要估計(jì)。

看下該因子從“very high”到“low”的評(píng)分遞減規(guī)律，我認(rèn)為，我們可以放心的假設(shè)，“very low”的評(píng)分不高于 0.82。

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

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

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

綜合所有因素

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

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

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

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

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

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

評(píng)估注意事項(xiàng)

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

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

我們最終使用單點(diǎn)值代替了范圍，那是因?yàn)槲覐墓浪惴秶镞x擇了最有利于 Kotlin 的值，將所有的估計(jì)都轉(zhuǎn)換成了單點(diǎn)值。

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

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

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

請(qǐng)記住，由于我們將估計(jì)壓縮成了對(duì) Kotlin 而言最為有利的單點(diǎn)值，所以其他可能的結(jié)果會(huì)顯示出更大的 Kotlin 切換開(kāi)銷(xiāo)。因此，在所有可能的結(jié)果中，我們?cè)谏衔拿枋龅膯吸c(diǎn)值是最有利于 Kotlin 的。

小結(jié)

在文章開(kāi)頭部分，我們展示了一些可能會(huì)對(duì)開(kāi)發(fā)人員比較編程語(yǔ)言造成誤導(dǎo)的主觀判斷。

接下來(lái)，我們討論了客觀比較編程語(yǔ)言存在的困難，并進(jìn)行了一系列的估計(jì)，以便弄清楚 Kotlin 棧與 Java 棧完成軟件項(xiàng)目所需的總工作量。在執(zhí)行估計(jì)時(shí)，我們一直使用估計(jì)范圍里最有利于 Kotlin 的值。

通過(guò)我們的分析，從 Java 切換到 Kotlin 似乎會(huì)導(dǎo)致完成軟件項(xiàng)目所需的總工作量增加。

更多的工作意味著企業(yè)切換到 Kotlin 需要花更多的錢(qián)才能獲得同樣的功能，而用戶(hù)需要等待更長(zhǎng)的時(shí)間才能獲得產(chǎn)品。

有些開(kāi)發(fā)人員可能會(huì)吃驚，覺(jué)得這個(gè)結(jié)果不容易接受。

在考慮了所有的情況之后，谷歌最終決定支持 Kotlin Anroid 開(kāi)發(fā)。對(duì)此，谷歌可能需要相當(dāng)大的投入——谷歌云平臺(tái)團(tuán)隊(duì)是不是沒(méi)有人可以做類(lèi)似的分析，從而弄清楚切換到一門(mén)新語(yǔ)言所帶來(lái)的負(fù)面影響?

我認(rèn)為，谷歌員工都是非常聰明的人，我相信他們?cè)跊Q定支持 Kotlin 之前已經(jīng)進(jìn)行了非常深入的分析。