[譯] Airbnb 在 React Native 上下的賭注（三）：建立一個跨平臺的移動端團隊

ALVIN君發表於2019-03-01
AIReact Native

建立一個跨平臺的移動端團隊

使用 React Native 適應移動端

[譯] Airbnb 在 React Native 上下的賭注（三）：建立一個跨平臺的移動端團隊

這是系列部落格文章中的第三篇，本文將會概述使用 React Native 的經驗，以及 Airbnb 移動端接下來要做的事情。

除了 React Native 數不清的技術優勢和缺陷之外，我們還了解到 React Native 對於一個工程組織意味著什麼。採用它比在現有平臺新增新庫或模式要複雜得多。這同時也帶來了一些組織上的挑戰。與通常可以有效解決的技術挑戰不同，組織上的挑戰更難以發現，糾正和恢復。不過值得慶幸的是，我們的手機文化是健康的，但在考慮 React Native 時有很多事情需要注意。

React Native 呈現出兩極化

根據我們的經驗，工程師們在剛接觸 React Native 時候，提出了截然不同的觀點，從讚揚它將會成為集 Android、iOS 和 Web 的銀彈，到完全反對在團隊中 React Native 的任何使用。在正式投入使用了之後也是這樣的情況。一些團隊有著令人難以置信的經歷，而其他團隊則為此後悔不已，並重回原生的懷抱。

根本原因

在使用 React Native 時，存在一些不可避免的錯誤，改進和效能問題。但是，有很多動人的東西：

  1. React Native 本身迭代速度很快。
  2. 我們可以同時進行基礎架構和功能的開發。
  3. 工程師們可以一起學習 React Native，這門語言對每個人相對來說都是比較新的。
  4. 我們在開發和正式生產環境中進行除錯的文件和指南有時不一致，可能會造成混淆。

因此，通常很難找到問題的根本原因。有時候，不清楚問題出在哪個團隊，或者這個問題是不是 React Native 固有的問題。

React Native 仍然需要原生

一個常見的誤解是，React Native 允許你完全不用編寫原生程式碼。然而，事情並不是這樣的。React Native 的原生基礎有時還會繼續向前發展。例如，每個平臺上的文字渲染略有不同，鍵盤處理方式不同，並且預設情況下在 Android 上旋轉時重新建立 Activity。一個高質量的 React Native 體驗，需要仔細地保持不同平臺的平衡。再加上，開發者難以精通三種平臺上的專業知識，因此在開發中始終難以實現優質體驗。

跨平臺除錯

大多數工程師都能精通一或兩個平臺。很少有人能同時精通 Android、iOS 和 React。儘管成熟的 React Native 環境中，絕大多數工作都是通過 JavaScript 和 React 完成的，但有時構建或除錯某些東西需要鑽研原生的東西。這些情況可能導致工程師在他們從未使用過的平臺上除錯時，陷入專業知識之外的困境。更糟糕的是，由於根本原因難以確定，工程師甚至不確定往什麼方向定位問題。

持續招聘

儘管我們投入使用 React Native，但我們移動端的野心和團隊仍在同步擴大。然而，通過社群口碑，許多人開始將 Airbnb 與 React Native 聯絡起來，甚至有人認為我們的應用是 100％ React Native。儘管事實遠非如此，但許多 Android 和 iOS 工程師也因此不願意申請來 Airbnb。以防你是其中之一，我們還在招人呢！

混合應用很難實現

100％ 原生或 100％ React Native 的路相對簡單。但是，一旦你在程式碼庫中混合使用了，就會出現許多新問題。你如何分配你的團隊？團隊如何協作？如何在你的應用中共享狀態？如何確保程式碼得到測試？工程師如何在三個平臺上進行有效除錯？如何決定使用哪個平臺來實現新功能？如何在整個組織中聘用和分配資源？這些都是非常重要的需要解決方案的問題，如果你沿著這條路一直走下去，就不可避免地會出現這些問題。

三種開發環境

為了成為一名高效率的 React Native 工程師，擁有穩定且最新的 React Native、Android 和 iOS 環境非常重要。對於像 Airbnb 這樣大的組織來說，每個平臺都需要大量時間來配置，學習並保持最新狀態。短短几周後，常常意味著要花費幾個小時，才能使所有東西都恢復到最新狀態。

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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

相關文章