为生产力而生：数据揭示Kotlin的开发者效率优势

多年的生产力导向设计现在已可在数据中看到。

务实精神从一开始就是 Kotlin 设计的核心。该语言优先考虑开发者的便利性和生产力，而不是学术纯粹性或功能野心。

开发者对 Kotlin 工作的描述相当一致：更多时间花在你试图构建的东西上，更少时间花在仪式上。满足编译器的仪式更少，在进入核心部分之前需要编写的样板代码也更少。多年来，一个有趣的问题是，这种效果是否也能在规模上显现。

现在有数据了。JetBrains Research 最近一项研究测量了约 2800 万个示例中从第一次编辑到推送的时钟时间。在可比较的工作上，Kotlin 开发者花费的时间比使用 Java 的开发者少约 15%–20%。

这种差距现在更为重要，因为越来越多的代码由 AI 代理编写，而开发者将更多时间花在阅读、审查和验证代码上。我们将在最后回到这一点。

生产力源于设计：简短的历史

当你看它所产生的特性时，务实就变得具体了。以下是十多年来语言和生态系统设计决策中的五个例子。

数据类

某些模式在每个代码库中重复出现。值对象、DTO、消息信封和配置记录——Kotlin 在一个声明中捕获了这些形态。

data class User(val id: Long, val name: String, val email: String)

只有一行代码，值类型的行为，最少的样板代码。你可以自动获得相等性、哈希、结构解构、toString() 和 copy() 构造函数。添加一个字段不需要手动重写六个方法。

空安全

Kotlin 的类型系统会追踪值是否可能为空，编译器会阻止你忽略这个问题。一整类运行时错误变成了编译时反馈。

val length: Int = user?.profile?.email?.length ?: 0

可空链用一行代码表示，编译器会验证每一步。缺失的值在编译时暴露，而不是稍后在生产中。

小胜利

一些特性在每次调用站点悄悄地消除摩擦。智能类型转换 在类型检查发生后消除了冗余的类型声明。带默认值的命名参数 使配置变得可读，无需构建器模式。尾随 Lambda 将基于块的 API 变成像普通控制流一样易读。

每一个都很小。但合在一起，它们塑造了一个典型函数的样子：

fun createUser(
    name: String,
    role: Role = Role.MEMBER,
    email: String? = null,
) = transaction {                       // 尾随 lambda
    val user = Users.insert(name, role, email)
    if (email != null) {                // 智能类型转换：email 现在为 String
        sendWelcome(email.lowercase())
    }
    user
}

createUser(name = "Anton", role = Role.ADMIN)   // 命名参数 + 默认值

三个特性结合成一个简短且可读的函数。

协程和结构化并发

Kotlin 中的异步工作读起来像普通代码。suspend 函数看起来是顺序执行的，但实际上并发执行，并且结构化并发将每个异步操作绑定到启动它的作用域——这样就不会有任务在后台悄悄逃逸。

DSL 作为一等公民

生产力并未止步于语言本身。相同的语法决策——尾随 lambda、扩展函数、类型安全的构建器——还催生了整个生态系统中 IDE 感知的 DSL 文化：Gradle 构建脚本、Compose UI、Ktor 路由、Exposed SQL，以及 HTML 和 JSON 构建器。每一个都是编译器能够理解的原生代码的配置面，而不是需要记忆的独立格式。

这些都不是孤立的胜利。每一个都是相同务实承诺的产物。本文的其余部分将审视这一承诺的整体表现。

故事无法回答的问题

多年来，开发者一直这样描述 Kotlin：更少的仪式，更多的时间在实际工作上。但描述并非测量。同样的效果是否也会在数字中显现，在一个团队的意见不占主导的规模下，这是一个不同的问题。

故事无法规模化，自我报告存在已知的偏见，包括显而易见的偏见：选择 Kotlin 的人希望这种选择是合理的。一个更隐蔽的偏见是，那些短暂尝试 Kotlin 然后又回去的开发者可能永远不会被采样。研究可以填补这个空白。

研究发现

在一项近期研究中，JetBrains Research 团队分析了 IntelliJ IDEA Ultimate 在 20 个月窗口期（2023年11月至2025年6月）内的遥测数据，涵盖约 32 万名开发者以及 2800 万个开发周期。本研究中，一个周期是指从一次推送后首次编辑源文件到下一次推送该文件之间的时钟时间。

对于小任务（约十分钟的编辑），Kotlin 周期平均比 Java 周期短约 15.7%。对于中等任务（约半小时），短约 20.3%。对于大任务（一个半到两小时），短约 15.1%。绝对值上来看，一个短修复节省一两分钟，一个中等任务节省五到七分钟，一个长任务节省 15–20 分钟——在工作日和季度中重复多次。这一模式在任务大小和 20 个月的窗口期内都保持一致。

显而易见的问题很合理。Kotlin 和 Java 项目的规模是否不同？开发者经验水平是否不同？某些 Kotlin 团队是否比与之比较的 Java 团队更新或资源更充足？

大量的工作用于排除这些因素。该研究比较了同一开发者在从 Java 迁移到 Kotlin 前后的表现，并与同期继续使用 Java 的开发者进行了对比——这是一种纵向设计，将语言变化与团队或项目差异隔离开。工作按任务大小分桶，因此比较不会将一行代码的调整与功能构建混为一谈。JDK 版本被用作工程文化的代理，比较在有和没有该控制的情况下进行。模式仍然存在。

完整的方法论——纵向设计、控制变量、有效性检查以及研究能声称和不能声称的边界——都在 JetBrains Research 文章中。从这开始，是我们（Kotlin 方面）如何看待这些结果。

更大的发现：Kotlin 项目不会变慢

单个任务上 15%–20% 的差距是真实的，但这并非头条新闻。更大的发现在于轨迹。纵观同一类工作在项目生命周期中的变化，数据讲述了一个与时间点数字不同的故事。

在研究样本中，Java 项目在 20 个月窗口期内变慢了。随着代码库的增长，周期变长了 9%–17%——无论小、中、大任务。相同模式在数据的独立切片中也出现：Java 项目越老，同类工作所需的时间越长。Kotlin 项目几乎没有表现出这种变慢。一些 Kotlin 迁移者甚至在同期有所改善，在窗口期结束时对可比任务的工作速度比开始时更快。

这与我们从可维护性方面多年来听到的说法是一致的：Kotlin 代码更易于维护。六个月后回来，你仍然能理解你写的内容。

直到现在，这些报告与生产力报告一直是分开的观察。它们越来越像从两个角度看到的同一个发现。

以下是我们对原因的理解——明确是我们的解读，而非研究旨在证明的结论。Kotlin 代码比等效的 Java 代码更清晰地表达了意图。类型携带更多信息。习惯用法在团队之间和时间内更加统一。更少的工作被编码成下一个读者必须重新构建的模式。

如果这个解释是正确的，那么轨迹结果就说得通。一个保持可读性的代码库不会积累那种逐渐将 10 分钟改动变成 15 分钟改动的摩擦力。这种差别在第一天可能不明显。但在规模上，复利效应是不可否认的。

这在人工智能时代意味着什么

随着 AI 辅助编写和代理工作流变得越来越普遍，开发者现在花在审查、集成、拒绝和调整代码上的时间比亲自编写代码的时间更多。即使在没有全面采用代理的团队中，这种转变也在改变日常活动的分布。开发者的更多工作是判断那段代码是否应该存在。

两个既定事实并存。首先，开发者大部分时间用于阅读代码而不是编写代码。80/20 的估计成为行业俗语是有原因的——它出现在研究中、回顾中、任何对工作日如何度过的诚实盘点中。其次，在可比较的工作上，Kotlin 开发者完成周期的速度明显快于 Java 开发者。

合理的解释是，节省的时间是阅读时间。阅读是时间花费最多的地方，而 Kotlin 似乎让阅读变得更快。

在代理工作流中，这一点更为重要。对 AI 生成变更的代码审查就是阅读。验证一个提议的实现是否如其所声称的那样就是阅读。将其集成到现有系统中是阅读。拒绝一个糟糕的建议从阅读开始。开发者一周内敲键盘的时间比例已经下降了两十年，现在正在急剧下降。花在阅读和理解上的时间则相反。

能让你读得更快——并信任你读到内容的语言——对于现代软件开发来说要引人注目得多。

Kotlin 还内置了更多的静态保证。非空性在类型层面得到强制执行。一旦你检查了类型，类型收窄会自动发生。密封层次结构加上详尽的 when 表达式可以在编译时回答“代理是否遗漏了一个分支？”的问题。使 Kotlin 代码读得更快的相同特性也使其在机械验证上更快——在审查之前由编译器验证，之后由人类审阅者验证。

这种安全性在代码不是你亲自编写时尤其有价值。

数据中的生产力优势在 AI 之前就已经存在，而软件开发方式的变化可能使这一优势比以往任何时候都更加重要。第一天差距、轨迹优势以及代理工作流案例都指向同一方向。

要点

对于开发者： 多年来凭直觉进行的团队讨论现在有了数据支撑。下次有人质疑 Kotlin 是否真能为 Java 团队带来收益时，你可以用具体数据来支撑你的回答。

对于技术领导者： 新的 JVM 服务的量化案例现在已经可见。较小的第一天效应和更大的轨迹效应都对你有利。对于任何你预计需要维护超过一年的东西，后者尤为重要。

务实精神产生了一种语言，其回报随时间复利——并且随着开发者角色的演变而变得更重要，而非更不重要。

链接：

• JetBrains Research 文章——完整方法和注意事项
• Kotlin 后端开发——框架、部署和迁移路径
• 在线尝试 Kotlin——Kotlin Playground