作者：Gabriel Peal
翻译：Rebecca Han
用 React Native 适配全世界的移动端
这是 Airbnb 对外输出使用 React Native 的经验以及下一步在移动端做些什么的系列博文第三篇。
React Native 除了技术上数不清的优缺点外，我们还学到了 React Native 之于工程师团队来说有多么重要意义。采用 React Native 比向现有的平台增加新的库或者模式要复杂得多。这样做带来了一些组织上的挑战。与技术上的挑战通常能够有效的解决不同，组织上的挑战很难被发现，修正和恢复。庆幸的是，我们的移动端文化很健康，但考虑到 React Native 时，还是有不少问题需要注意。
React Native 是两极分化的
在我们的经验里，工程师们对于 React Native 的看法大相径庭，从称赞它是将 Android，iOS 和 web 联合在一起的银子弹，到完全反对在他们的团队中使用 React Native 褒贬不一。即便使用了 React Native 后也会发生同样的情况。一些团队有好得难以置信的体验，而另一些则觉得后悔并重新拥抱原生。
根本原因
在使用 React Native 时，有一些难以避免的 bugs， polish（这个翻译无力了。。。）和性能上的问题。然而，还有很多变动的部分：
React Native 本身变动很频繁
我们同时在做基础设施和功能特性的开发
工程师们是同事学习 React Native，且它相对于每个人来说都是全新的。
我们开发中的文档和 debug 指引，与产品在同一时间是不一致的，这会令人很困惑。
所以，经常很难找出问题的根本原因。又是也很难判断这个问题应该归结于哪个团队，或者是否是 React Native 本身固有的问题。
React Native 仍然是原生的
一个通常的错误观念是 React Native 可以让你完全的避免写原生代码。然而这并不是目前的现状。React Native 的原生根基有时还是非常有存在感的。例如，文本的渲染在每个平台上都略有不同，键盘的处理也不一样，在Android 上默认情况下，手机转动后 Activites 会重新创建。高质量的 React Native 开发体验依赖于两个原生领域知识量相对的平衡。这一点，再加上需要在三个平台上有相当知识水平是比较难的，使得始终有用高质量的体验是十分不容易的。
跨平台调试
大多的工程师会相对熟悉一两个平台，一个人在 Android，iOS，React 三个方面都有很高技术水平的情况非常少见的。尽管一个成熟的 React Native 生态中大量的工作已经用 JavaScript 和 React 做好了，有时仍然要深入的原生层面构建或者调试一些东西。这些情况使得工程师在超出其专长外，他们从来没有用过的平台上去做调试的时候陷入困境。当工程师没有办法确定根本问题出在哪里的时候，情况会更糟糕。
招聘
虽说我们大量投入在 React Native 上，我们在移动端的野心和团队组建仍然在同步加速。即便如此，通过社区的传播，许多人开始把 Airbnb 和 React Native 联系起来，甚至不少人相信我们的 app 是百分之百用 React Native 开发的。尽管这远不是事实，但结果却是许多 Android 和 iOS 工程师在应聘 Airbnb 时犹豫。如果你恰好是其中一员，我们依旧在招聘哦！
Hybrid Apps 很难
100%原生或者100% React Native 的路径是相对简单直观的。当你在代码库里有混合的使用，就会冒出很多新的问题。如何拆分团队？团队间怎么合作？跨 app 如何共享状态？怎么保证所有的都做了测试？工程师怎么有效的跨平台调试？怎样决定新的功能在哪个平台上使用？在组织间如何招聘和分配资源？这些都是些如果你走这条路就无法规避，但又没什么切实解决办法的问题。
三种开发环境
为了成为高效的 React Native 工程师，拥有用一个稳定且更新到最新的 React Native ，Android，iOS 环境是十分重要的。对于 Airbnb 这样庞大的团队来说，每个平台都需要大量且必要的时间来装载，学习及保持更新。
在原生和 React Native 之间平衡
在很多情况下，问题的最佳解决方案是介于原生和 React Native 之间的。例如，我们导航的实现使用了 Activities 和 ViewControllers，大部分的代码用的还是每个平台原生代码。经常发生的是，你并不能很清楚的知道这段代码是应该用原生写，还是用 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 资源相对于原生来讲过度的投资在了教育和培训上。
这是 Airbnb 对外输出使用 React Native 的经验以及下一步在移动端做些什么的系列博文第三篇。
- 第一弹：在 Airbnb 使用 React Native （译文）
- 第二弹：技术 （译文）
- 第三弹：组建一个跨平台移动端团队 （译文）
- 第四弹：在 React Native 方面做个决定 （译文）
- 第五弹：在移动端接下来要做的事情 （翻译中…）