返回 登录
1

Kotlin这些问题 Pinterest工程师都是怎么解决的?

原文:The Case Against Kotlin
作者:Ryan Cooke
翻译:黑色巧克力

译者注:作者作为已采用Kotlin编程的Pinterest工程师,以问题对应解决方案的方式全面介绍了Kotlin。下面请看译文。

使用Kotlin开发App需要下很大的决心。现在看来,在技术成熟曲线上,Kotlin也许接近“过高期望的峰值”(即早期公众的过分关注演绎出了一系列成功的故事,当然同时也有众多失败的例子)。你可以看到大量赞美Kotlin的博客广播视频,这篇文章先假设你了解其中的益处,然后我们将深入分析面对Kotlin所提供的机遇,Android开发人员将有怎样的挑战。Kotlin并不适合每个团队,任何新语言的采用都需要考虑其代价。

(尽管本文是看待采用Kotlin所带来的一些挑战,但我们积极的在Pinterest中使用Kotlin。记得查看我们关于从Java转移到Kotlin的一些建议,并持续阅读我们关于Kotlin的其他文章。)


image

问题:学习曲线

客观的说,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%。

解决方案:编译时间


image

我们测试了一个项目的编译时间,先后进行了比较。发现大部分的编译时间消耗都来自于转换一个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字节码,通过反编译,然后修复一些奇怪的东西。反编译不会增加符合团队代码质量标准的代码,如果真这么做的话,就可能需要重新评估变量命名的工作量了。


image

假设有五个工程师来学习和评估Kotlin,每个人转换五个文件,然后添加另外五个文件。现在有50个Kotlin文件,如果决定反对Kotlin,那么将花费大量的时间来将文件转换回来,如果转换的文件已经变更了多次版本,就不是很有用。如果使用Anko或其他类似的Kotlin库,或者甚至是高级的Kotlin功能,那么这是逆转版本的另一层复杂性。

开发过程中Kotlin造成问题,就必须去解决,无论有多大的困难和阻碍。从代码库中删除Kotlin并不是一个选项。

解决方案:可逆性

在评估Kotlin的时候,可逆性也是很重要。这一项很容易添加,但需要确保没有使用Kotlin,因为它太难删除。编写测试代码,是评估新技术很好的开始。如果开始转换应用程序文件,那就从转换良好的单元测试文件开始。如果有问题,它们还会转回Java变得更加容易。

总结

学习曲线、编译时间、开发稳定性和静态代码分析都将变得更好。谷歌正式支持这门语言标志着Kotlin将变得更好。将Kotlin添加到代码库中永远不会太迟,但删除它可能为时已晚。

我们在Pinterest上使用Kotlin,并与它一起生活成长。这篇文章的重点是提醒你考虑Kotlin的风险,同时很多问题将会得到更快解决。

评论