Kotlin vs Java 在现代代码库中的 Android 应用开发
Source: Dev.to
开始一切的时刻
让我记起的那一刻发生在一次比预期更久的代码审查中。房间里除了笔记本电脑的嗡嗡声几乎寂静无声，终于有人半开玩笑地说：
“这个文件感觉比整个应用还老。”
我们都明白他们的意思。代码还能运行，但它背负的沉重感已经不再符合产品如今的体验。
就在那时，问题再次浮现——不是作为争论，而是作为一种反思：当我们决定如何编写应用时，真正选择的是什么语言？
当 Java 看起来是唯一的选择时
我在 Android 开发仍显得僵硬却让人安心的时期开始使用 Java。规则清晰，模式熟悉。能够准确知道事物的行为方式让人感到舒适，即使达到目标需要付出努力。
- Java 强迫我必须明确。每一个意图都必须写清楚。
- 起初，这让人觉得安全。
- 随着时间推移，尤其是应用规模扩大、期望变化时，这种明确感开始显得沉重。
那时我并未质疑它。这只是 Android 应用的构建方式。
Kotlin 进入对话的那一天
Kotlin 对我来说并没有伴随喧闹而来。它悄悄出现在副项目中，随后慢慢进入生产讨论。有人会提到更简洁的语法。还有人会提到因空指针处理而导致的崩溃更少。
吸引我注意的不是速度或风格，而是代码在我离开几周后再次阅读时的感觉。我能更快地理解它。我还能记起做出决定的原因。
这种感觉比我预期的更重要。
阅读代码才是日常工作
我大部分时间并不是在写新代码，而是阅读已经存在的代码——跟随可能已经离开团队的人的逻辑，重新审视我几乎记不清的决定。
- Java 代码 常常像合同一样：清晰、结构化，有时让人感到疲惫。
- Kotlin 代码 更像一次对话——仍然精准，但语气更轻松。
在现代代码库中，这种差异会影响团队在一天结束时的疲劳感。
Safety Feels Different in Practice
- Java 教会了我纪律。安全来自仪式感；你通过结构来证明正确性。
- Kotlin 教会了我意识。安全来源于意图；你更直接地表达什么应该存在、什么不应该存在。
这种转变减轻了心理负担：防御性检查更少，对某些东西是否可能为 null（而实际上不应该）的疑惑也更少。
迁移从不只是技术层面
我从未见过仅凭语言特性驱动的顺畅迁移。迁移往往发生在团队感受到无法再忽视的摩擦时。
- 以 Java 为主的代码库会以特定方式老化：样板代码成倍增加，小改动需要触及许多位置，审查变慢，因为上下文散布在各处。
- 当团队转向 Kotlin 时，他们往往是想恢复工作流，而不是追求新奇。
混合代码库讲述真实故事
大多数真实的应用不会一夜之间切换。它们会变成双语——Java 和 Kotlin 并肩存在，各自展示出它们的编写时间。
这些混合代码库如实讲述了成长的历程：早期的基础使用 Java，后来的层次采用 Kotlin。随着时间推移，重心会自然转移。
我已经学会不急于推进这一过程。语言的转换更多反映团队的舒适度，而非技术准备度。
现代 Android 期望改变了平衡
Android 应用今天的行为与多年前不同：状态更多，后台工作更多，与系统行为的集成也更多。
Kotlin 更适合许多团队的这种现实——并不是因为 Java 处理不了，而是因为 Kotlin 减少了围绕这些关注点的噪音。更少的代码用于防止错误，让人有更多空间思考行为。
当冗余成为商业成本
在大规模时，冗余会消耗时间——不仅是编写时间，还包括阅读、审查和维护的时间。
我看到团队因为代码需要持续关注而难以快速推进。并不是因为代码错误，而是因为它太“吵”。
Kotlin 能让一切变得更安静。当截止日期紧迫、团队规模扩大时，这种安静尤为重要。
为什么 Java 仍然有其位置
尽管如此，Java 对我来说并没有消失。代码库的某些部分可以多年保持稳定，而 Java 的显式特性正适合这种稳定性。
- 了解事物的工作方式而不依赖新构造会让人感到安心。
- 对于长期存在的组件，这种可预测性仍然有价值。
在有意使用时，现代代码库通常能从两种语言中受益。
Teams Feel Language Choices Emotionally
I’ve noticed how language choices affect conversations.
- Kotlin code reviews feel lighter; discussions focus on behavior rather than structure.
- Java reviews tend to focus on correctness and completeness. That’s not a flaw—it’s a different energy.
Teams thrive when their tools match how they think and work today, not how they worked years ago.
团队对语言选择的情感感受
我注意到语言选择会影响对话。
- Kotlin 代码审查 感觉更轻松；讨论更关注行为而非结构。
- Java 审查 往往侧重于正确性和完整性。这不是缺陷——只是一种不同的能量。
当团队的工具与他们今天的思考和工作方式相匹配，而不是过去几年的方式时，团队会更有活力。
将这些选择应用于真实项目
在不同项目中工作——包括那些由移动应用开发团队主导、时间线和期望紧迫的项目——我看到语言选择会产生连锁反应。
- 新开发者的入职感受不同。
- Bug 修复的感受不同。
- 重构时的信心不同。
这些结果很少体现在性能指标中，而是体现在团队对工作讨论的方式上。
这个问题很少是关于更好还是更差
当人们问“Kotlin 与 Java”时，他们通常想要一个结论。我已经不再给出结论了。
更好的问题是 哪种语言能够支持应用当前的生命周期阶段——早期增长、快速变化、长期稳定。
现代代码库不是静态的。它们在不断演进。语言的选择也应该随之演进。
Ending With the Code Review That Started It All
那次代码审查在没有决定的情况下结束。没有强制指令。没有路线图。只有一种共识：需要进行改变。
几个月后，新的文件以 Kotlin 编写，未作任何公告。旧的 Java 文件仍然保留在原处，默默支撑着把团队带到今天的基础。
它们如此。代码库悄然调整。
这就是大多数有意义的转变发生的方式。不是通过声明，而是通过一次又一次的小而稳健的选择，让日常工作变得更轻松。