原文地址：https://medium.com/airbnb-engineering/building-a-cross-platform-mobile-team-3e1837b40a88
（科学上网）

---

Building a Cross-Platform Mobile Team

建立一个跨平台团队

This is the third in a series of blog posts in which we outline our experience with React Native and what is next for mobile at Airbnb.
In addition to the countless technical pros and cons of React Native, we learned a ton about what React Native means for an engineering organization. Adopting it is much more complex than adding a new library or pattern to an existing platform. Doing so brought to light a number of organizational challenges. Unlike technical challenges which can often be solved or effectively worked around, organizational challenges can be harder to detect, correct for, and recover from. Thankfully, our mobile culture is healthy but there are a number of things to be aware of when considering React Native.

这是一系列博客帖子中的第三篇，我们在这篇博文中概述了我们在React Native方面的经验以及Airbnb的移动应用程序。

除了React Native的无数技术优点和缺点之外，我们还了解到React Native对于工程组织意味着什么。 采用它比向现有平台添加新库或模式要复杂得多。 这样做揭示了一些组织方面的挑战。 与通常可以解决或有效解决的技术挑战不同，组织挑战难以发现，纠正和恢复。 值得庆幸的是，我们的移动文化是健康的，但在考虑React Native时有很多事情需要注意。

React Native is Polarizing

In our experience, engineers approached React Native with wildly different opinions varying from praising it as a silver bullet that united Android, iOS, and web to being wholly against any use of React Native on their team. The same situation occurred after using it as well. Some teams had an incredible experience while others regretted it and reverted back to native.

React Native两级分化

根据我们的经验，工程师向React Native提出了截然不同的观点，从赞扬它成为连接Android，iOS和Web的框架到完全反对任何在团队中使用React Native。 使用它之后也出现了相同的情况。 一些团队有着令人难以置信的经历，而其他团队则为此感到遗憾，并回归原生。

Root Cause Attribution

While working on React Native, there were inevitable bugs, polish, and performance issues. However, there were many moving pieces:
React Native itself moves quickly.
We were doing simultaneous infrastructure and feature development.
Engineers were learning React Native together and it was relatively new for everybody.
Our documentation and guidance for debugging in development and production was inconsistent at times and could be confusing.
As a result, it was often difficult to find the root cause of a problem. Sometimes, it wasn’t clear which team an issue should be attributed or whether the issue was inherent to React Native.

归根究底

在使用React Native时，存在不可避免的错误，抛bug和性能问题。 但是，有很多快速迭代的部分：
React Native本身迅速迭代。
我们正在同时进行基础架构和功能开发。
工程师们一起学习React Native，对每个人来说都是相对较新的。
我们在开发和生产中进行调试的文档和指南有时不一致，可能会造成混淆。
因此，找到问题的根本原因通常很困难。 有时候，不清楚哪个团队应该归因于什么问题，或者该问题是否为React Native固有的问题。

React Native is Still Native

A common misconception is that React Native allows you to move away from writing native code entirely. However, that is not the current state of the world. The native foundation of React Native still rears its head at times. For example, text is rendered slightly differently on each platform, keyboards are handled differently, and Activities are recreated on rotation by default on Android. A high-quality React Native experience requires a careful balance of both worlds. This, paired with the difficulty of having balanced expertise on all three platforms makes shipping a consistently high-quality experience difficult.

React Native仍然是原生的

一个常见的误解是，React Native允许您完全不用编写原生代码。 但是，这不是现状。 React Native的原生基础有时还会继续发展。 例如，每个平台上的文本呈现略有不同，键盘处理方式不同，并且默认情况下在Android上旋转时重新创建活动。 高质量的React Native体验需要两个平台（iOS、Android）的谨慎平衡。 这与所有三种平台上均衡专业知识的困难相伴随，这使得开发始终难以实现高质量的体验。

Debugging Across Platforms

Most engineers are proficient at one or two platforms. It is exceedingly rare for somebody to be highly competent in Android, iOS, and React. Even though the vast majority of work in a mature React Native environment is done with JavaScript and React, there are times when building or debugging something requires digging into native. These situations can lead to engineers getting stuck way out of their expertise trying to debug an issue on a platform they have never used. This is made worse when an engineer isn’t even sure where to look due to the difficulty of root cause attribution.

跨平台调试

大多数工程师精通一个或两个平台。 对于在Android，iOS和React中高度胜任的人来说，这是极其罕见的。 尽管成熟的React Native环境中的绝大多数工作都是使用JavaScript和React完成的，但有时构建或调试某些东西需要挖掘本机。 这些情况可能导致工程师陷入他们的专业知识尝试在他们从未使用过的平台上调试问题的方式陷入困境。 由于根本原因归因的困难，工程师甚至不确定在哪里寻找时，情况会变得更糟。

Hiring

Even though we were investing in React Native, our mobile ambitions and teams continued to accelerate in parallel. However, through word of mouth in the community, many people began to associate Airbnb with React Native and some even believed that our app was 100% React Native. Even though this was far from the truth, many Android and iOS engineers were hesitant to apply to Airbnb as a result. Just in case you are one of them, we are still hiring!

招聘

尽管我们正在投资React Native，但我们的移动野心和团队仍在同步加速。 然而，通过社区口碑，许多人开始将Airbnb与React Native联系起来，甚至有人认为我们的应用程序是100％React Native。 尽管事实远非如此，但许多Android和iOS工程师因此而不愿意申请Airbnb。 以防万一你是其中之一，我们仍在招聘！(看到这里，我居然会心一笑？？)

Hybrid Apps Are Hard

The path of a world that is 100% native or 100% React Native is relatively straightforward. However, once you have a mix within your codebase, many new issues arise. How do you split up your teams? How do teams collaborate? How do you share state across your app? How do you ensure that things get tested? How do engineers effectively debug across three platforms? How do you decide what platform to use for a new feature? How do you hire and allocate resources across your organization? These are all problems with non-trivial solutions that will inevitably arise if you go down this path.

混合应用程序很难

100％原生或100％React Native的世界的路径相对简单。 但是，一旦你在代码库中混合使用，就会出现许多新问题。 你如何分割你的团队？ 团队如何协作？ 你如何在你的应用中分享状态？ 你如何确保事情经过测试？ 工程师如何在三个平台上进行有效调试？ 你如何决定使用什么平台来实现新功能？ 你如何在你的组织中聘用和分配资源？ 这些都是非常重要的解决方案的问题，如果你沿着这条路走下去，这些解决方案将不可避免地出现。

Three Development Environments

In order to be an effective React Native engineer, it is important to have a stable and up-to-date React Native, Android, and iOS environment. For an organization as large as Airbnb, each platform requires a significant amount of time to set up, learn, and keep up to date. Returning after just a few weeks often meant spending several hours getting everything back up to date.

三个发展环境

为了成为一名有效的React Native工程师，拥有稳定且最新的React Native，Android和iOS环境非常重要。 对于与Airbnb一样大的组织，每个平台都需要大量时间进行设置，学习并保持最新状态。 短短几周后回来常常意味着要花费几个小时才能使所有事情都恢复到最新状态。

Balancing Native vs React Native

There are many situations in which the optimal solution for a problem spans native and React Native. For example, our navigation implementation makes heavy use of Activities and ViewControllers and most of its code is native to each platform. Often times, it is not clear whether code should be written in native or React Native. Naturally, an engineer will often choose the platform that they are more comfortable which can lead to unideal code.

平衡原生与RN

在许多情况下，问题的最佳解决方案跨native和React Native。 例如，我们的导航实现大量使用Activities和ViewControllers，其大部分代码都是原生的，适用于每个平台。 很多时候，代码是否应该用native或React Native编写是不明确的。 当然，工程师通常会选择他们更舒适的平台，这可能导致代码不合理。

Cross-Platform Testing

We found that engineers would primarily develop on one platform over the other due to convenience or comfort. Often, they would assume that if it works on the platform they tested on, it would work perfectly on the other. Most of the time, this was true which is a testament to the power of React Native. However, it was untrue often enough that it ended up causing frequent issues late in QA cycles or in production.

跨平台测试

我们发现，由于方便性或舒适性，工程师将主要在一个平台上进行开发。 通常，他们会假设如果它在他们测试的平台上工作，那么它将完美工作。 大多数情况下，这是对React Native强大的证明。 然而，它往往不足以导致在QA周期后期或生产中频繁发生问题。

Split Teams

Teams that worked in native as well as React Native often faced both technical and communication challenges. Once the codebase was split between native and React Native, the code became fragmented. Sharing business logic, models, state, etc. became more challenging and engineers no longer had the expertise to work across the entire flow. We knew that this would happen from the get-go but thought that this might be balanced by an increased collaboration with web. A few teams did start to share resources and code across web and mobile but most weren’t able to realize this potential benefit.

拆分团队(或者译为 团队分工？)

在本地以及React Native工作的团队经常面临技术和沟通方面的挑战。 一旦代码库在native和React Native之间拆分，代码就会变得碎片化。 共享业务逻辑，模型，状态等变得更具挑战性，工程师不再具备在整个流程中工作的专业知识。 我们知道这会从一开始就发生，但认为这可能会通过与web的更多合作来平衡。 一些团队确实开始通过网络和移动设备共享资源和代码，但大多数团队无法实现这一潜在利益。

Perceived Iteration Speed

One of our qualitative goals with React Native was to increase development speed. Often, React Native features were written by a single engineer instead of one for each platform. From the perspective of a React Native engineer, if it takes them 50% longer to write their feature than it would on Android or iOS, it feels longer to them even if it takes fewer hours overall.

感知迭代速度

我们与React Native的定性目标之一是提高开发速度。 通常，React Native功能是由单个工程师编写的，而不是针对每个平台编写的。 从React Native工程师的角度来看，如果他们花费的时间比在Android或iOS上花费的时间长50％，即使整体花费的时间更少，他们的感觉也会更长。

Public Resources and Documentation

Android and iOS have had ten years and millions of engineers contributing to learning resources, open source, and online help. We leverage many resources such as CodePath to help people learn Android and iOS. Even though React Native has one of the largest cross-platform communities and can leverage React resources, it is still much smaller than Android and iOS. That paired with the fact that we had to build most of our infrastructure in-house meant that our limited React Native resources were over-invested in education and training relative to native.

公共资源和文档

Android和iOS已有十年的时间和数百万的工程师为学习资源，开源和在线帮助贡献力量。 我们利用CodePath等许多资源来帮助人们学习Android和iOS。 尽管React Native拥有最大的跨平台社区之一，并且可以利用React资源，但它仍然比Android和iOS小得多。 这与我们必须在内部构建我们大部分基础设施的事实意味着我们有限的React Native资源相对于本地资源而言过度投资于教育和培训。

---

This is part three in a series of blog posts highlighting our experiences with React Native and what’s next for mobile at Airbnb.

这是一系列博文中的第三部分，重点介绍了我们在React Native方面的经验以及Airbnb的移动应用。

---

如有侵权，请即刻告知。