原文：The Case Against Kotlin
作者：Ryan Cooke
翻译：黑色巧克力
译者注：作者作为已采用Kotlin编程的Pinterest工程师，以问题对应解决方案的方式全面介绍了Kotlin。下面请看译文。
使用Kotlin开发App需要下很大的决心。现在看来，在技术成熟曲线上，Kotlin也许接近“过高期望的峰值”（即早期公众的过分关注演绎出了一系列成功的故事，当然同时也有众多失败的例子）。你可以看到大量赞美Kotlin的博客、广播和视频，这篇文章先假设你了解其中的益处，然后我们将深入分析面对Kotlin所提供的机遇，Android开发人员将有怎样的挑战。Kotlin并不适合每个团队，任何新语言的采用都需要考虑其代价。
（尽管本文是看待采用Kotlin所带来的一些挑战，但我们积极的在Pinterest中使用Kotlin。记得查看我们关于从Java转移到Kotlin的一些建议，并持续阅读我们关于Kotlin的其他文章。）
客观的说，Kotlin并不是主流的开发语言，最近才进入最受欢迎的编程语言top50的名单。如果你计划在基础代码中使用Kotlin，你需要教会团队中的每个开发人员如何去使用它，以及如何去维护代码。即使Kotlin不再受欢迎，你也需要继续训练开发人员（也许他们对学习Kotlin并没有兴趣）。
现在谈谈学习曲线。学习曲线会降低开发速度，并且培训过程可能缓慢。开发人员需要很好地学习Kotlin，才能自信地阅读这门语言。虽然一些开发人员会进行自学，但团队仍然需要为他们留出训练时间，以跟上学习进度。新开发人员学习Kotlin时，一次训练是不够的。此外，那些只受过培训却很少在工作中接触Kotlin的开发人员，当他们转移到需要编写Kotlin代码的时候，也可能需要再次学习。
有一点非常重要，最初的一周是适应Kotlin，有很多学习任务要完成。即使是最有经验的Kotlin开发人员也在学习技巧和方法以便做得更好，所以这是整个团队需要学习的。如果团队中没有Kotlin专家，那就需要认识到，没有标准的标准等同于根据高效进行Java开发这本书来确定最佳实践。打造属于自己的最佳实践可能既费时又棘手，但对于解决类似的问题，有必要采取一致的方法。
解决方案：学习曲线
第一个解决办法就是要认识到将Kotlin添加到代码库中是对Kotlin寿命持续增长的赌注。如果赌注是正确的，那么维护代码和学习将会变得缺少挑战性。如果赌注是错误的，那么Kotlin将成为科技债务。谷歌的官方支持是Kotlin留下来的重要原因，但这种支持并不会总是持续下去。
学习Kotlin的资源有很多，比如Koans和优秀的书籍。最有效的是有一个Kotlin的提倡者，指导和鼓励团队。
开发速度是Kotlin的初始卖点。很少有开发人员认识到这一点，当团队找到有Kotlin经验或者Kotlin专家，并且稳定性没有问题时，开发人员的速度将会提升，然而我们还没达到那一步。
问题：编译时间
Kotlin会让编译时间变得更糟。在相当数量的Gradle编译时间中，有超过30秒的增量编译时间和大约75秒的清理编译时间，而Kotlin约占清理编译时间的25%，占增量编译时间的40%。
解决方案：编译时间
我们测试了一个项目的编译时间，先后进行了比较。发现大部分的编译时间消耗都来自于转换一个Kotlin文件。对于清理编译依然缓慢，因为需要转换更多的Kotlin文件（好在转换带来的减速影响并不大）。
好的一方面是除了Kotlin的初始添加之外，不管转换了多少文件，增量和无更改编译时间仍然保持不变。通过转换一个文件，可以很好地了解编译时间有哪些。这里使用Gradle-Profiler来进行性能分析，提供了一个准确的、客观的编译时间投射。
问题：开发稳定性
在我们的团队中，不喜欢Kotlin的人并不是真的不喜欢它，只是因为害怕，或者因为更愿意等着看应用程序崩溃，以找出合适的空处理，甚至只是因为var和val看起来很相似。他们不喜欢它的最简单的原因便是，当有一个问题出现会阻碍编写代码和开发效率。
这里发生多次的问题你也可能遇到。例如遇到增量编译对某些开发人员不起作用，切换分支总是需要一个清理编译。编译失败随机发生，因为kapt（Kotlin注释处理器工具）有时会读取内存错误。此外，Kotlin并没有很好地支持Instant Apps，启用Kotlin插件的同时，Android Studio的崩溃也在增加。就开发而言，如果你认为一切都是稳定的，就会出现意想不到的问题。
因为多数开发人员并不熟悉Kotlin和kapt工具，这就可能导致一旦出现大量的时间消耗，就被认为Kotlin的错误。例如，开发人员缺失一条导入语句，而编译失败显示了很多kapt错误。由于不熟悉Kotlin，开发人员认为是Kotlin造成的问题，便不会调查如何简单的修复。这种“古怪”与实际的稳定性问题相结合，意味着需要消耗大量的维护时间。
解决方案：开发稳定性
最好的解决办法是在稳定的基础上谨慎地升级。Kotlin，Gradle，Android Studio和其他所有的东西都将到达一起稳定工作的状态，但它经常提示新版本。如果想使用最新的Android Studio或者类似的更新，这是很困难的。如果你决定积极升级，可以为所经历的问题提交bug，Google团队响应性很好，乐于解决任何问题。如果你不想要处理bug，就谨慎升级保持稳定。
问题：静态代码分析
Java是一门成熟的编程语言，有许多非常棒的静态代码分析工具。这意味着不需要自己检查代码是否遵循规则和约定。现有的工具如FindBugs、PMD、Error Prone、Checkstyles和Lint都很好。开发人员通常希望避免做一些导致问题的事情，但要每个员工都记住所有的事情，进行代码检查，这是不可能的。毕竟我们不是机器人，这就是为什么要给机器定规则，告诉我们编译失败，或编译错误。在没有静态代码分析工具的情况下，开发者更容易犯错。
解决方案：静态代码分析
这是个有待解决的问题，我的想法是Lint规则和检查应该在Kotlin的Android Studio 3.0上派上用场。例如最近测试在Canary Android Studio版本中“删除所有未使用的资源”，而检查删除的工具只在Kotlin使用，Android Studio并没有。如果有兴趣的话，你可以开发自己的静态代码分析程序。
为了平衡缺乏静态代码分析，主要的Kotlin特性比如空处理（减少了代码审查者发现的潜在错误），Android Studio开发人员需要认真去考虑。
问题：可逆性
可逆性是一种便于撤销变更或决定的能力。Kotlin是不可逆的，虽然将Java文件转换为Kotlin很容易，但从Kotlin转换到Java的最佳方法是查看Kotlin字节码，通过反编译，然后修复一些奇怪的东西。反编译不会增加符合团队代码质量标准的代码，如果真这么做的话，就可能需要重新评估变量命名的工作量了。
假设有五个工程师来学习和评估Kotlin，每个人转换五个文件，然后添加另外五个文件。现在有50个Kotlin文件，如果决定反对Kotlin，那么将花费大量的时间来将文件转换回来，如果转换的文件已经变更了多次版本，就不是很有用。如果使用Anko或其他类似的Kotlin库，或者甚至是高级的Kotlin功能，那么这是逆转版本的另一层复杂性。
开发过程中Kotlin造成问题，就必须去解决，无论有多大的困难和阻碍。从代码库中删除Kotlin并不是一个选项。
解决方案:可逆性
在评估Kotlin的时候，可逆性也是很重要。这一项很容易添加，但需要确保没有使用Kotlin，因为它太难删除。编写测试代码，是评估新技术很好的开始。如果开始转换应用程序文件，那就从转换良好的单元测试文件开始。如果有问题，它们还会转回Java变得更加容易。
总结
学习曲线、编译时间、开发稳定性和静态代码分析都将变得更好。谷歌正式支持这门语言标志着Kotlin将变得更好。将Kotlin添加到代码库中永远不会太迟，但删除它可能为时已晚。
我们在Pinterest上使用Kotlin，并与它一起生活成长。这篇文章的重点是提醒你考虑Kotlin的风险，同时很多问题将会得到更快解决。