更多的工作意味着企业切换到 Kotlin 须要花更多的钱才能获得同样的功能，而用户须要等待更长的时光才能获得产品。

就剩编码与调试子晃荡了。

如不雅我们用 Kotlin 调换 Java，那么我在编码与调试晃荡中可以节俭若干工作量?这个问题很难答复，不合法度榜样员之寄┞封一数值会有很大年夜差别(有些法度榜样员应用 Java 更高效)。不过，既然我们在评估最好的情况，我们不妨假设大年夜 Java 切换到 Kotlin 可以将开辟人员在编码与调试阶段的临盆力平均进步 10%。

10%的临盆力晋升是一个不实际到令人吃惊的数值。即使我们在文本编辑器中手工输入所有代码，那也是不实际的。推敲到现如今 IDE 的功能，这一数值更是不实际。推敲到有些开辟人员应用 Java 更高效，这个数值就毫无事理了。

我不介怀应用如许一个既不实际又对 Kotlin 评估有利的数值，因为我知道，不管它对评估结不雅产生了如何不切实际的积极影响，一旦我们抛开个中部分“幻想的假设”，由此带来的负面影响会抵消掉落那些积极影响。

那么，在编码与调试方面晋升了 10%——我们把产品交付给客户的速度快了若干?

我们也可以把这个例子扩大到天然说话。我懂得三门截然不合的说话。固然它们之间差别很大年夜，但我发明，当我不睬解文本中应用的单词时，浏览任何一种说话的文本都异常艰苦。一旦我熟悉构成文本的单词并熟悉高低文——无论它应用了哪一种说话，我读起来都不艰苦。

下面这张图片来自 Code Complete 一书，展示了软件项目标各类晃荡所占的比例：

我本身在多门说话上有过这种体验：Verilog、Bash、Perl、Tcl、Lisp、Java。

图小项目以构建晃荡为主。大年夜点的项目须要更多架构、集成和体系测试工作来包管项目成功。这张图没有显示需求，因为和其它晃荡不一样，需求工作不是直接的法度榜样功能。(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 ，第二版

根据来自 Code Complete 的┞封张图片，在一个较大年夜的软件项目中(多于 10K 行)，编码和调试只占项目总工作量的不足 20%。

是以，在一个较大年夜的软件项目中，我们所假设的编码和调试效力晋升 10%，只能将完成项目所需的总工作量缩减 2%。

例如，一个须要 5 人年才可以完成的项目(这是比拟较较大年夜的 Android 项目)，总工作量的 2%为：

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

如不雅我们真得可以或许把项目工作量削减 24 人-天，这会是一个大年夜 Java 切换到 Kotlin 的很好的来由。然而，我们应当还记得，上述积极评估是在幻想情况下得出的，其基本是不切实际的假设。

在真实世界里，切换到别的一门编程说话会产生弗成避免的影响，我们将评估这种影响，并与上述幻想化评估作个比较。

开辟人员预备

为了评估最好的情况，我们假设开辟人员可以急速大年夜 Java 切换到 Kotlin。

实际上，固然 Kotlin 和 Java 异常类似，但开辟人员仍然须要花一些时光来进修，然后再花一些时光来调剂开辟实践和对象。预备时光因人而异：有些开辟人员可以三四天完成切换，其他人则须要 10 天甚至更多的时光。

让我们乐不雅一点，平均每个开辟人员只要 5 天就可以大年夜 Java 切换到 Kotlin。

一个须要 5 人年才能完成的项目会有 3 到 5 名开辟人员(最好的情况下)。平均每个开辟人员的切换时光为 5 天，如许，一个项目总计就须要 15 到 25 小我天的切换时光。

切换到 Kotlin 所节俭的工作量(乐不雅估计)与切换所需的总工作量似乎差不多。

开辟人员技能损掉

我们已经评论辩论了这项技能的个一一个方面(代码可读性)，但还有很多其他方面。昔时夜一门说话切换到另一门时，与旧编程说话相干的部分技能可以应用到新说话上，但该技能的其他部分会损掉掉落。

为了评估编程说话技能损掉对项目工作量的影响，我们将应用源自 Cocomo2 评估模型的“说话与对象体验”因子：

说话与对象经验(LTEX)

该指标用于衡量开辟软件体系或子体系的项目团队应用编程说话和软件对象的经验。软件开辟包含借助对象完成需求、表示情势设计与分析、设备治理、文档提取、库治理、法度榜样样式与格局化、一致性检查、筹划与控制等等。除了项目编程说话经验外，项目支撑对象集的经验也会影响开辟工作。经验低于 2 个月会获得一个很低的评级，有 6 个月或多年的经验则会获得一个很高的评级，见下表：

Cocomo 2 模型定义手册

例如，假设我们有一个 Java 开辟团队，团队成员平均有一年的经验，我们想迁徙到 Kotlin。

因为 Kotlin 和 Java 异常像，与很多 Java 对象兼容。我们可以乐不雅地假设，在经由初步的预备后，开辟人员就可以归为有 6 个月开辟经验这一类(而不是低于 2 个月)。根据这个假设，为了评估技能损掉所导致的额外工作，项目标额定工作总量应当乘以 1.09。

一个须要 5 人年完成的项目，配备了平均具有 1 年 Java 经验的开辟人员，切换到 Kotlin 所导致的额外工作达到了令人咂舌的 108 人天。

技能损掉所导致的额外工作是切换到 Kotlin 所缩减的工作的四倍。

说话和对象的稳定性和成熟度