Airbnb RN经验总结 - 第三篇
引言
我们总结无数的技术优缺点,同样认识到 RN 对于工程团队的影响。
适配 RN 比新增开源库或模式要复杂的多,而且给团队带来了挑战。
团队挑战不像技术问题可以解决或者有替代方案解决,它更难发现、修正和恢复。
庆幸的是,我们的移动团队文化很健康,但考虑使用 RN 仍然要考虑很多问题。
RN 正在走向极端
从我们的使用经验来看,采用 RN 的工程师有着截然不同的观点,有的认为 RN 是一枚银弹,统一三端,
有点则完全反对团队内使用 RN。同样的情形在使用 RN 后发生。
有些团队觉得很好,有点则完全后悔使用 RN, 直接回归原生。
根本原因归属
使用 RN 的过程中,有很多 bug、优点和性能问题。
- RN 本身更新迅速
- 我们完善基础设施,同时进行功能开发
- 工程师们一起学习 RN,对每个人来说都很新
- 针对开发调试和线上调试的文档和指南有时不全,导致难以理解
结果经常很难发现问题的根源,有时都不清楚那个团队出了问题或者来自 RN
RN 仍然属于原生
RN 比较常见的误解是允许开发者快速编写原生代码,但是明显不是真实情况。
RN 的原生基础仍然盛行,例如,文本在不同平台渲染效果不一致,
键盘处理完全不同,android 切换屏幕方向时默认重新创建 Activity。
高质量 RN 使用需要谨慎考虑两个方向平台之间的平衡。
精通三个平台的难度成为 RN 高质量开发的最大障碍。
跨平台调试
大部分工程师只熟悉一到两个平台。
很少人能够同时掌握安卓、IOS 和 React。
即使在 RN 环境下主要使用 JS 和 React 开发,但打包和调试时仍然要深入原生。
这就会导致工程师卡在他们不熟悉的领域,尝试去解决完全没用过的平台问题。
这种情形在根本原因很复杂时,工程师甚至无法确定问题来源,会变得更加糟糕。
招聘
即使我们在 RN 上投入很多,但我们移动端目标和团队仍在并行发展。
但是经过社区的口口相传,许多人开始把 RN 和公司关联在一起,有些甚至以为
我们的应用 100%用 RN。
虽然事实不是这样,结果许多安卓和 IOS 工程师依然犹豫是否要投简历。
如果你是其中一员,我们依然在招聘。
混合应用很难
完全原生开发或完全 RN 开发的路径相对比较直接。但是,一旦你在两者直接混合开发,
将会出现很多新问题。如何分割团队?团队之间如何协作?跨应用之间如何共享状态?
如何决策哪个平台使用新特性?如何招聘并跨组织协调资源?
这些都是之前没有尝试解决方案的问题。如果选择混合开发,问题将会接踵而至。
三种开发环境
为了成为高效的 RN 开发工程师,保持稳定实时更新的三端环境十分重要。
对于 airbnb 这样的大型团队,每个平台需要相当多的时间配置,学习和保持更新。
几周时间后回归团队就意味着要花费数小时来更新一切环境。
权衡原生和 RN
很多时候最佳解决方案原生和 RN 都可以实现。例如,导航可以用 Activity 和 ViewControllers 实现,
大部分代码都是平台原生代码。有时都不确定代码应该用原生还是 RN.
一般工程师都会选择自己熟悉的平台实现,导致不理想的代码实现。
跨平台测试
我们发现工程师为了方便,基本都开发一个平台,他们会认为一个平台测试通过了,其他平台也可以用。
大部分时间,由于 RN 的魔力,这种想法是对。 但是在后续的 QA 环节或生产环境中,经常会产生很多问题。
团队分割
采用混合式开发的团队经常会面临技术和沟通上的挑战。一旦代码在两个平台分离,代码变得碎片化。
共享业务逻辑、模型和状态等等会变得更加艰难,工程师们也无法掌握整个流程每个环节。
我们一开始就知道会发生这种情况,却认为可以通过和 web 紧密合作达到平衡。
很少团队真的开始在 web 和移动端共享资源和代码,但大部分不知道其中潜在的优势。
表面迭代速度
RN 的一项重要目标是提升开发速度。RN 功能通常由一个工程师开发,而不是针对每个平台。
从 RN 工程师的角度,开发相同的功能时长会比原生平台长 50%。
公开资源和文档
安卓和 IOS 平台已经发展数十年,数万计的工程师贡献了很多学习资源,开源库和在线帮助。
我们也在 CodePen 上提供很多资源帮助人们学习安卓和 IOS。
即使 RN 有着最庞大的跨平台社区,同时利用 React 资源,但仍然比原生平台要小的多。
我们不得不自己创建大部分的基础工具,和原生相比,RN 学习和培训资源却十分有限。
译者注
-
原文有删减,因译者水平有限,如有错误,欢迎留言指正交流