原文地址：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 上下的賭注（三）：創建一個跨平臺的移動端團隊