写点什么

访谈:Kotlin 在 Pinterest 的逆势生长

  • 2018-10-09
  • 本文字数:3696 字

    阅读完需:约 12 分钟

InfoQ 最近采访了 Pinterest 核心 UI 团队的 Android 工程师 Christina Lee,讨论了 Pinterest 对 Kotlin 的采用情况、Pinterest 在采用过程中面临的挑战、从中总结的主要经验教训、从 Java 过渡到 Kotlin 的技巧,以及她即将在 KotlinConf 2018 上进行的演讲主题 Representing State: the Kotlin Edition

InfoQ:请你简单介绍一下自己和你在 Pinterest 的角色(特别是在支持采用 Kotlin 方面)。

Christina Lee:我是 Christina,Pinterest 核心 UI 团队的一名 Android 工程师。几年前,我所在公司被 Pinterest 收购,我也因此加入了 Pinterest。在之前那家公司,我有多年完全自由使用 Kotlin 的经验。因此,当我开始加入 Pinterest 时,很自然地将这种经验和热情带入我的新工作中。在 Pinterest 的几个星期内,我被授权在我当时负责的功能上试用 Kotlin(Android 的视频支持)。这项工作以及一些相关的内部倡导工作,最终导致我们的 Android 应用程序大量使用 Kotlin。今年,我们的新策略是将 Kotlin 作为 Android 的首选开发环境。

InfoQ:Kotlin 的哪些方面促使你成为 Kotlin 倡导者?

Lee:Kotlin 并没有彻底偏离 Java,因为它们都为 JVM 生成字节码。它之所以如此好用,是因为它本质上是内置了最好的编程实践的另一个 Java 版本,用它做对事情比做错事更容易。开发人员能够快速、自信地进行编码,并消除了使用 Java 时所需的大量工作。因为编码就像写作一样,是一种富有表现力的艺术形式,有了这样的工具,你就可以清楚、快速、准确地表达自己的想法。当你将其与行业领先的语言工具和互操作性以及 JetBrains 团队表现出的全面而深思熟虑的语言领导力相结合时,很难不爱上它。

InfoQ:Pinterest 在采用 Kotlin 期间面临了哪些组织层面的挑战?Pinterest 是如何克服这些挑战的?

Lee:在采用 Kotlin 期间我们遇到的最大挑战之一是持续出现的 Kapt(Kotlin 注解处理器)和其他与构建相关的问题。CI 构建环境经常出现错误,并且在本地切换分支时经常出现构建失败,因为构建状态未能被正确清除。因为这些问题的存在,有些高级工程师甚至提议放弃这门语言。采用一门年轻的编程总是会伴随着日益增长的痛点——Kapt 本身存在固有的 big——而这些 bug 不是我们自己能够解决的。随着 Kapt 和相关构建工具得到改进,这类问题也得到了解决,但在很多工程师的心目中,Kotlin 已经与构建不稳定性联系在了一起,他们对这门语言有了偏见。

不过,有一部分原因是第一次采用新技术时都不可避免会出现的盲点。这些是我们有能力在内部解决的问题,我们通过培训来解决这些问题。比如,我们在编译时会遇到的一个常见的问题,即开发人员会忘记导入语句或者犯了一些与 Kotlin 无关的错误,但 Kapt 在 Android Studio 中输出信息的方式导致很难在构建输出中找到这些错误。教会他们可以在哪里找到真正的编译时错误,这样以后他们就可以自己找到这些错误。为了解决这类问题,我们的团队专门设立了几个 Slack 频道,专门用于询问有关 Kotlin 或构建的问题,并开创了一个先例,即欢迎提出任何问题,这些问题都会得到回应。向团队讲授 Kapt 等新组件的工作原理、有用的错误信息类型以及从哪里开始寻找解决方案,这对缓解 Kotlin 的痛点大有裨益。

InfoQ:你是如何说服你的团队使用 Kotlin 重新构建整个 Android 代码库的?

Lee:在 Pinterest,我们的策略是优先使用 Kotlin,但并不是只能用 Kotlin。也就是说,所有的 Pinterest Android 开发人员必须知道如何阅读、编写和理解 Kotlin,因为它是我们公司主要的 Android 开发语言,所有新代码都必须使用 Kotlin 编写。不过,我们也强调,不要去转换那些没有合理理由去转换的现有 Java 代码。这背后有双重的逻辑。首先,“如果没有 bug,就不要去修复它”。如果某些代码可以正常运行,而你修改了它,可能会破坏现有的行为。除非将代码转换为 Kotlin 有明显的 ROI,否则最好让工作组件继续不受干扰,直到有必要引入其他变更。其次,将 Pinterest 代码库中的每个文件都转换为 Kotlin 需要大量的时间,这是一笔巨大的投入。在我们看来,花费开发人员这么多时间可能得不偿失。

InfoQ:Pinterest 在采用 Kotlin 时学到的最大教训是什么?

Lee:作为一个正常人,我也有一点叛逆性格。我不喜欢别人告诉我要做什么,所以我认为,在决定是使用 Kotlin 还是 Java 时,每个 Pinterest 的开发人员都应该参与做出决定。从技术角度来看,由于 Kotlin 与 Java 之间卓越的互操作性,这完全是有可能的,但它并未考虑到人性。人们不喜欢不确定性,当一个团队很容易形成不同的阵营(Java 团队、Kotlin 团队),那么有关 API 设计或可空性模式等问题的对话就很容易变成“我们与他们”之间的对立。通过让语言在公司内部有机地传播,我们最终达到了一个平衡点,大部分热衷于尝试使用新语言的开发人员都采用了这门语言,其他不感兴趣的开发人员可以选择退出。

如果时间足够,这种有机路径最终可能会改变所有开发人员,但在很长一段时间内,团队将处于分裂状态。当我们的平台负责人 Sha Sha Chu(与其他工程主管一起)决定将 Kotlin 作为首选语言时,我们担心人们会因为他们的选择被忽略而感到不安。我们针对这一过程进行了讨论,但在政策推出后,团队凝聚力和幸福感似乎大幅提升。根据这一经验,我认为 Pinterest 最大的经验教训是在探索的早期阶段要提供明确和直接的指导,以最大限度地减少团队处在分裂状态的时间。作为一个团队,我认为我们已经更加深入地意识到进行全面测试的价值,然后迅速回归单一的路径(要么完全放弃,要么全力以赴)。

另一个重要的经验是 Kotlin(尤其是早期)的构建有点不稳定,直到我们分配了足够的资源来监控和解决出现的问题(特别是与 CI 和 Kapt 相关的问题)。这些问题都不是不可克服的,但它们确实需要一些深思熟虑的调查,这些都需要占用工程师的时间。我们在开始时没有为此分配适当的资源,导致早期在诊断构建失败原因时所花的时间超过了预期。在为这个问题分配了专用的资源之后,我们就能够在相对较短的时间内修复问题。针对待命工程师的投入带来了巨大的回报,在未来推出新的框架部署时,我们可能会尝试做类似的事情。

InfoQ:关于从 Java 到 Kotlin 的转换,你有哪些有用的技巧可以分享?

Lee:关于 Kotlin 的入门(包括来自 Huyen Tue Dao 和我的演讲)现在有很多资源可参考,几乎任何学习方式都应该能够找到能够简化从 Java 过渡到 Kotlin 的内容。除了各种免费讲座和教程之外,IntelliJ 系列 IDE 也是最好的学习工具。它们提供了复制和粘贴 Java 代码并将其自动转换为 Kotlin 的功能。这样就可以粗略地知道 Java 概念将会被翻译成什么样的新语言,就像在学习新语言时,Google Translate 可以为你提供粗略的语言翻译。编辑器可能会给出一些不正确的建议,但这些建议仍然会带有有用的错误信息,可以在 StackOverflow 上轻松查找问题的答案。

此外,代码评审很关键。与大多数编程语言一样,在 Kotlin 中也有很多方法可以完成代码评审任务。随着人们逐渐加入 Kotlin 的行列,我们指定了特定的 Kotlin 评审人员检查来自新手的拉取请求。他们的作用不是判断底层代码的技术健全性,而是关注语言的使用方式以及它们是否符合最佳实践和我们推荐的风格指南。这些代码评审促进了组织学习的传播——写代码的人收到了建议,评审人员在提出问题和意见时必须更深入地思考语言本身,讨论内容被记录下来,其他团队成员可以阅读或参考它们。

InfoQ:你在 KotinConf 2018 的演讲内容是什么?你为什么要选择这个主题?

Lee:我今年在 KotlinConf 上的演讲是关于 Kotlin 语言特性如何让我们能够更轻松、更准确地定义应用程序的离散状态。我对这种定义良好的数据结构主题充满热情,因为它在代码评审和架构讨论中经常被忽略,但却是无数问题和错误的根源。要保持一间干净的房间的整洁是相对容易的,与之类似,在项目开始时投入时间来设置和维护逻辑数据结构可以更容易让代码做正确的事情,这对开发者来说是速度方面的胜利,对用户来说是稳定性方面的胜利。

InfoQ:感谢你抽出宝贵时间接受我们的采访。你还有什么想与 InfoQ 读者分享的吗?

Lee:Kotlin 最吸引我的是我不记得有哪个开发人员在彻底采用这门语言后有感到后悔的。我使用 Swift 的经历告诉我,人们喜欢这门语言,但由于构建时间、互操作性或语言版本迁移方面的问题,导致他们对切换到 Swift 感到遗憾。根据我的经验,批评 Kotlin 的声音主要来自那些尚未开始使用这门语言的人,而只有极少数是来自那些已经深入使用这门语言的人。有几个人跟我争论好几个月是否要采用 Kotlin,但是在转向 Kotlin 几个星期后,他们来到我的办公桌前,告诉我说,Kotlin 让他们再次激起了他们开发 Android 的热情。我知道,最初不愿意采用 Kotlin 的开发人员现在在抱怨他们需要切换回 Java 维护旧代码。在我看来,这种能够吸引最不情愿的开发人员的能力是对语言本身、围绕它的工具以及引导采用这门语言的团队的最好佐证。

有关 Pinterest 采用 Kotlin 的更多信息,请访问 Pinterest工程博客。读者还可以访问 InfoQ Java 主页,了解所有与 Java 相关的新闻。

查看英文原文 Kotlin Q&A With Christina Lee of Pinterest

2018-10-09 10:447384
用户头像

发布了 731 篇内容, 共 447.2 次阅读, 收获喜欢 2001 次。

关注

评论 1 条评论

发布
暂无评论
发现更多内容

华为云IoT体验:基于IoT平台构建智慧路灯应用

乌龟哥哥

2月月更

深入浅出 ESM 模块 和 CommonJS 模块

局外人

JavaScript node.js 前端 前端开发 模块化

跨平台移动APP开发进阶(一):mui开发注意事项

No Silver Bullet

App 跨平台 2月月更 mui

springboot druid 数据库连接池连接失败后一直重连

Jeremy Lai

验收测试驱动开发后记

Bruce Talk

敏捷 Agile User Story

[架构实战营] 模块九作业

Geek_0ed632

「架构实战营」

无人管的 InfoQ 每周精选

scruel

InfoQ

《人月神话》第十九章阅读笔记:20年后的《人月神话》

panda

人月神话 概念完整性 阅读笔记

在线ASCII Banner艺术字生成工具

入门小站

工具

iOS开发·备战2022金三银四-runtime原理与实践: 消息转发详解篇

iOSer

ios runtime iOS面试 ios开发 金三银四跳槽

基于 SAP BTP 平台的 AI 项目经验分享 | 社区征文

汪子熙

人工智能 机器学习 AI 新春征文 2月月更

第十节:SpringBoot中的日志管理

入门小站

spring-boot

跨平台应用开发进阶(三): uni-app 实现资源在线升级/热更新

No Silver Bullet

uni-app 更新 版本升级 2月月更

如何快速开发 Serverless Devs Package ?

Serverless Devs

Serverless

简析Web3 架构:前端、后端和数据

devpoint

区块链 dapp Solidity Web3.0 2月月更

给 zsh 自定义命令添加参数自动补全

mzlogin

Shell zsh

架构实战营模块二作业-微信朋友圈复杂度分析

炎彬

「架构实战营」

自省与反思(一)

懒时小窝

反思 反思总结

模块二作业

blazar

「架构实战营」

Web Components 系列(五)—— 详解 Slots

编程三昧

前端 组件化 2月月更 WebComponent

程序员,如何避免无效会议?

蜜糖的代码注释

2月月更

微信朋友圈高性能复杂度分析

「架构实战营」

项目遇到突发问题,如何给上级做汇报?

石云升

项目管理 项目经理 2月月更

渗透利器 | 常见的WebShell管理工具

喀拉峻

网络安全

模块 7 作业

miliving

微信朋友圈业务架构分析

Geek_1b4338

#架构实战营 「架构实战营」

iOS开发备战金三银四·突击大厂的算法与底层原理复习方向

iOSer

ios iOS面试 iOS底层 金三银四跳槽 算法面试

DevOps进阶(二):DevOps 发展史

No Silver Bullet

DevOps 2月月更

蜜罐中利用jsonp跨域漏洞和xss漏洞的分析

H

网络安全 安全漏洞

Go 语言入门很简单:String

宇宙之一粟

Go 语言 2月月更

Web Components 系列—— 详解 Slots

CRMEB

访谈:Kotlin在Pinterest的逆势生长_Java_Kesha Williams_InfoQ精选文章