原文地址：Building a Cross-Platform Mobile Team: Adapting mobile for a world with React Native

原文做者：Gabriel Peal

译文出自：掘金翻译计划

本文永久连接：github.com/xitu/gold-m…

译者：ALVINYEH

校对者：DateBro

创建一个跨平台的移动端团队

使用 React Native 适应移动端

这是系列博客文章中的第三篇，本文将会概述使用 React Native 的经验，以及 Airbnb 移动端接下来要作的事情。前端

除了 React Native 数不清的技术优点和缺陷以外，咱们还了解到 React Native 对于一个工程组织意味着什么。采用它比在现有平台添加新库或模式要复杂得多。这同时也带来了一些组织上的挑战。与一般能够有效解决的技术挑战不一样，组织上的挑战更难以发现，纠正和恢复。不过值得庆幸的是，咱们的手机文化是健康的，但在考虑 React Native 时有不少事情须要注意。android

React Native 呈现出两极化

根据咱们的经验，工程师们在刚接触 React Native 时候，提出了大相径庭的观点，从赞赏它将会成为集 Android、iOS 和 Web 的银弹，到彻底反对在团队中 React Native 的任何使用。在正式投入使用了以后也是这样的状况。一些团队有着使人难以置信的经历，而其余团队则为此后悔不已，并重回原生的怀抱。ios

根本缘由

在使用 React Native 时，存在一些不可避免的错误，改进和性能问题。可是，有不少动人的东西：git

React Native 自己迭代速度很快。
咱们能够同时进行基础架构和功能的开发。
工程师们能够一块儿学习 React Native，这门语言对每一个人相对来讲都是比较新的。
咱们在开发和正式生产环境中进行调试的文档和指南有时不一致，可能会形成混淆。

所以，一般很难找到问题的根本缘由。有时候，不清楚问题出在哪一个团队，或者这个问题是否是 React Native 固有的问题。github

React Native 仍然须要原生

一个常见的误解是，React Native 容许你彻底不用编写原生代码。然而，事情并非这样的。React Native 的原生基础有时还会继续向前发展。例如，每一个平台上的文本渲染略有不一样，键盘处理方式不一样，而且默认状况下在 Android 上旋转时从新建立 Activity。一个高质量的 React Native 体验，须要仔细地保持不一样平台的平衡。再加上，开发者难以精通三种平台上的专业知识，所以在开发中始终难以实现优质体验。后端

跨平台调试

大多数工程师都能精通一或两个平台。不多有人能同时精通 Android、iOS 和 React。尽管成熟的 React Native 环境中，绝大多数工做都是经过 JavaScript 和 React 完成的，但有时构建或调试某些东西须要钻研原生的东西。这些状况可能致使工程师在他们从未使用过的平台上调试时，陷入专业知识以外的困境。更糟糕的是，因为根本缘由难以肯定，工程师甚至不肯定往什么方向定位问题。markdown

持续招聘

尽管咱们投入使用 React Native，但咱们移动端的野心和团队仍在同步扩大。然而，经过社区口碑，许多人开始将 Airbnb 与 React Native 联系起来，甚至有人认为咱们的应用是 100％ React Native。尽管事实远非如此，但许多 Android 和 iOS 工程师也所以不肯意申请来 Airbnb。以防你是其中之一，咱们还在招人呢！架构

混合应用很难实现

100％原生或 100％ React Native 的路相对简单。可是，一旦你在代码库中混合使用了，就会出现许多新问题。你如何分配你的团队？团队如何协做？如何在你的应用中共享状态？如何确保代码获得测试？工程师如何在三个平台上进行有效调试？如何决定使用哪一个平台来实现新功能？如何在整个组织中聘用和分配资源？这些都是很是重要的须要解决方案的问题，若是你沿着这条路一直走下去，就不可避免地会出现这些问题。oop

三种开发环境

为了成为一名高效率的 React Native 工程师，拥有稳定且最新的 React Native、Android 和 iOS 环境很是重要。对于像 Airbnb 这样大的组织来讲，每一个平台都须要大量时间来配置，学习并保持最新状态。短短几周后，经常意味着要花费几个小时，才能使全部东西都恢复到最新状态。post

Balancing Native vs React Native

在许多状况下，问题的最佳解决方案须要跨越原生和 React Native。例如，咱们导航的实现大量使用 Activity 和 ViewController，其大部分代码都是原生的，适用于每一个平台。但不少时候，不清楚代码是否应该用原生或 React Native 编写。固然，工程师一般会选择他们更温馨的平台，可是这可能致使代码不太理想。

跨平台测试

咱们发现，因为方便或温馨，工程师主要在一个平台上进行开发。一般，他们会假设若是它在他们测试的平台上正常工做，那么它在全平台同理也能完美运行。大多数状况下，这证实了 React Native 优点。然而，这每每不是真实的状况，它最终会致使在 QA 周期的后期或生产环境中频繁发生问题。

拆分团队

在原生以及 React Native 工做的团队，常常面临技术和沟通方面的挑战。一旦代码库在原生和 React Native 之间拆分，代码就会变得支离破碎。共享业务逻辑、模型、状态等变成更具挑战性的难题，工程师再也不具有在整个流程中工做的专业知识。咱们知道，这个问题从一开始就存在，但认为可能会经过与 Web 的更多合做来平衡。一些团队确实开始经过 Web 和移动设备共享资源和代码，可是大多数团队没有意识到这一潜在的好处。

感知迭代速度

咱们使用 React Native 的质量目标之一，就是提升开发速度。一般，React Native 的功能是由单个工程师编写的，而不是针对每一个平台编写的。从 React Native 工程师的角度来看，若是他们比在 Android 或 iOS 上花费的时间多 50％，即便整体的花费的时间更少，他们也会以为花费的时间更长。

公共资源和文件

Android 和 iOS 已有十年的时间了，有数百万的工程师为学习资源、开源和在线帮助都贡献了很多力量。咱们利用 CodePath 等许多资源来帮助人们学习 Android 和 iOS。尽管 React Native 拥有最大的跨平台社区之一，而且能够利用 React 资源，但它相比 Android 和 iOS 还小得多。再加上咱们必须在内部建设大部分基础架构，这一事实意味着，相对于原生资源，咱们有限的 React Native 资源在教育和培训上会投入过大。

这是系列博客文章的第三部分，重点讲述了咱们使用 React Native 的经验，以及 Airbnb 移动端接下来要作的事情。

若是发现译文存在错误或其余须要改进的地方，欢迎到掘金翻译计划对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

掘金翻译计划是一个翻译优质互联网技术文章的社区，文章来源为掘金上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注掘金翻译计划、官方微博、知乎专栏。

[译] Airbnb 在 React Native 上下的赌注（三）：创建一个跨平台的移动端团队