17 位谷歌 Android 开发专家是如何看待 Kotlin 的？

Google已经多次表达过他们不反对Kotlin的使用，只要Kotlin编译器依然生成有效的字节码，那么Google就不会阻止任何人使用它。但很多人依然在等待官方的正式支持，一件可能永远不会发生的事情。虽然我们等到了这一刻，但我想...

Google已经多次表达过他们不反对 Kotlin的使用，只要 Kotlin编译器依然生成有效的字节码，那么 Google就不会阻止任何人使用它。

但很多人依然在等待官方的正式支持，一件可能永远不会发生的事情。

虽然我们等到了这一刻，但我想如果能够知道 Google的 Android开发专家是如何看待 Kotlin的，那就更好了。

如果你没有听说过，那你应该了解下，Google开发专家（GDEs）[1]是一个旨在表彰优秀开发者对所在领域所作出的贡献的项目。

我联系了一些这样的 Android专家（人员列表很长！），我得到了来自 17位的答复。非常感谢你们这么好能够花时间来回答。

我只是要求他们告诉我们关于 Kotlin[2]的一点想法，答案显然是未经过修改的，所以你可以发现支持和反对（或者不那么支持）的声音。

我希望这有助于你知道 Kotlin是如何成为一个游戏规则改变者的，同时如果你是一名 Android开发者，我希望 Kotlin会成为你考虑使用的一门语言。

其他的就不多说的，让我们来看看 GDEs们的看法吧，排名不分先后：

我以前使用 Groovy编程语言开发过 Grails应用，对于我而言，Groovy是对 Java一个极大的改进。它很精简，并有助于避免当时使用 Java 6语言编码时不得不遇到的很多样板代码。当 Kotlin出现时，我立刻被它吸引了，因为它的很多语法特性让我想起了 Groovy。它既整洁又精炼。

我是一个狂热的学习者，所以我渴望学习 Kotlin并基于 Kotlin Koans开始我的学习之路。我也订购了《Kotlin in Action》的早期访问版本。当听了 Hadi的 Kotlin播客后，我被推到了正视 Kotlin的边缘。当 Kotlin 1.1发布后，我最终决定正视 Kotlin，并在我的线上应用中引入 Kotlin。

对于 Android开发者而言，Kotlin有很多优点。最明显的是它的类型系统和对空类型的处理，这迫使你在编码时指明哪些变量可为空，并在使用的时候遵循这个约定，之后编译器就会介入并确保对变量的赋值都是有效的。空指针异常[3]是我在 Android 应用程序中处理的最常见的异常类型。Kotlin有助于公平的竞争环境。

通过使用 Kotlin，我的代码变得更好了。

我真的真的很喜欢这门语言。我个人认为它在很多情况下使得编码变成一件愉快的事情，相比之前，同样的情况下用 Java语言编码将会感到痛苦和繁琐。我绝不是一个 Kotlin专家，因为我还没有在日常工作中使用它，但每次做小项目时我都会使用它。你知道传说中的 10倍效率的开发者吗？Kotlin有时让我觉得自己就像一个 10倍效率开发者（我一直不认为有人能够称为 10倍效率的开发者，所以这对我来说是一个好的开始）。

简洁的语法是这门语言非常明显的好处，除此之外，我真的很感激它提供的所有附加的 API和围绕它构建的生态系统。例如，不可变集合是我经常需要的东西，但如果不在应用中（部分）引入 Guava函数库的话，在 Java语言中是用不了的，但 Kotlin对不可变集合提供了一级实现，此外还有一堆的其他特性。哦，我说过当看到 Kotlin的发布版本将对 LLVM的支持作为一个目标时，我有多兴奋吗？

然而正如我刚才提到的，我的日常工作并没有使用 Kotlin。虽然有理由相信 Kotlin的引入将会使项目大大受益，但这个项目却很难引入 Kotlin，因为这个项目的团队规模很大，我苦恼的发现 Kotlin存在的主要问题：静态代码分析工具的缺乏和成熟设计模式的缺乏。

如果你的项目不大且不复杂，那么后者是一个相对次要的问题，但如果你遇到的是有十个开发者在一个有将近十年历史的巨大的代码仓库中协同工作时，具有良好的设计模式将会使你更加的安心。当然，你可以使用 Java设计模式，但并不是所有的 Java设计模式在 Kotlin中都是有意义的，因为有些设计模式是专门围绕 Java语言设计的，存在一定的局限性。这是一个漫长的讨论，我将在这里中止它，否则整篇文章就变成这个讨论了。

对我来说，前面提到的第一个问题是最关键的，也是真正决定我是否在项目中采用 Kotlin的关键。你在项目实践中使用不了 PMD，Checkstyle，Findbugs和其他的静态代码检查工具（还没有试过 Errorprone）的事实，将使你的项目陷入非常危险的处境。首先，如果项目中有超过 3～4位开发者，你不能指望在代码风格上面能够严格监督；更重要的，你缺少很多从上述工具中获得的深入的 bug检查功能。如果你从来没有（正确的）使用过静态代码检查工具，那么请举手，我当然不相信你！我知道现在有 IDE的检查，但那些功能还远不够强大；也有几个项目为 Kotlin带来了静态代码分析的能力，但它们还不值得让我们依赖。我真的很期待看到它们变得足够成熟，我们最终可以放心的使用它们。

在这期间，我在小的代码仓库上面使用 Kotlin，我喜欢它。

Kotlin迈出了 Android开发的一大步，在这之前，Android缺少 Kotlin所带来的特性，相比于其他的 Java平台，Android平台的 Java开发有些过时，即使现在有在推动 Java 8，但它还是不会变成我们喜欢的现代编程语言。

现在我看到的一个最大的问题是它的推广，说服公司转型到 Kotlin并展示它的价值很困难。对于技术型公司而言会相对简单，因为对于开发者来说是一个激励和挑战，但对于小公司来说更困难。此外，很多公司担心如果没有 Google在背后支持 Kotlin的话，将很难被广泛使用。

我喜欢这门语言以及它对生态系统的贡献，我希望能够在我的日常生活中更多地使用它，但我所从事的项目的性质不允许这样做。我鼓励大家都去看一下，但不限于 Kotlin，可能是另外一门语言，因为这会为他们打开一个新的视野，同时也是编写软件时非常有用的学习。

Kotlin是极好的，我喜欢它，它是 Android世界的一股清流。

虽然我也很喜欢 Kotlin，但我不认为它已经足够成熟到能够在线上产品中使用。成熟模式和最佳实践的缺乏，使得 Kotlin编写的代码可能难以维护。

从 Kotlin缺乏静态代码分析工具可以看出来。虽然 Java的静态代码分析工具不完美，但它们可以作为衡量技术债务的好指标。Java工具不能用于 Kotlin，因为它们专门分析的是 Java语言源码。

（编辑：无忧刷机网 - 51刷机网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!