前言

我在Lyft的八年間，很多產品經理以及工程師經常想往我們 app 里添加第三方庫。有時候集成一個特定的庫（比如 PayPal）是必須的，有時候是避免去開發一些非常復雜的功能，有時候僅僅只是避免重復造輪子。

雖然這些都是合理的考量，但使用第三方庫的風險和相關成本往往被忽視或誤解。在某些情況下，風險是值得的，但是在決定冒險之前，首先要能夠明確的定義風險。為了使風險評估更加的透明和一致，我們制定了一個流程來衡量我們將其集成到app有多大的風險。

風險

大多數大型組織，包括我們，都有某種形式的代碼審查，作為開發實踐的一部分。對這些團隊來說，添加一個第三方庫就相當于添加了一堆由不屬于團隊成員開發，未經審查的代碼。這破壞了團隊一直堅持的代碼審查原則，交付了質量未知的代碼。這給app的運行方式以及長期開發帶來了風險，對于大型團隊而言，更是對整體業務帶來了風險。

運行時風險

庫代碼通常來說，對于系統資源，和app擁有相同級別的訪問權限，但它們不一定應用團隊為管理這些資源而制定的最佳實踐。這意味著它們可以在沒有限制的情況下訪問磁盤，網絡，內存，CPU等等，因此，它們可以（過度）將文件寫入磁盤，使用未優化的代碼占用內存或CPU，導致死鎖或主線程延遲，下載（和上傳?。┐罅繑祿鹊?。更糟糕的是他們會導致崩潰，甚至崩潰循環。兩次。

其中許多情況直到 app 已經上架才被發現，在這種情況下，修復它需要創建一個新版本，并通過審核，這通常需要大量時間和成本。這種風險可以通過一個變量控制是否調用來進行一定程度的控制，但是這種方法也并非萬無一失（看下文）。

開發風險

引用一個同事的話：“每一行代碼都是一種負擔”，對不是你自己寫的代碼而言，這句話更甚。庫在適配新技術或API時可能很慢，這阻礙了代碼開發，或者太快，導致開發的版本過高。

庫在采用新技術或API時可能很慢，阻礙了代碼庫，或者太快，導致部署目標太高。每當 Apple 和 Google 每年發布一個新 OS 版本時，他們通常要求開發人員根據SDK的變化更新代碼，庫開發人員也必須這樣做。這需要協調一致的努力、優先事項的一致性以及及時完成工作的能力。

隨著移動平臺的不斷變化，以及團隊（成員）也不是一成不變，這將會成為一個持續不斷的風險。當被集成的庫不存在了，而庫又需要更新時，會花很多時間來決定誰來做。事實證明一旦一個庫存在，就很少也很難被移除，因此我們將其視為長期維護成本。

商業風險

如同我上面所說，現代的操作系統并沒有對 app 代碼和庫代碼進行區分，因此除了系統資源之外，它們還可以訪問用戶信息。作為 app 的開發者，我們負責恰當的使用這部分信息，也需要為任何第三方庫負責。

如果用戶給了 Lyft app 地理位置授權，任何第三方庫也將自動得獲得授權。他們可以將那些（地理位置）數據上傳到自己服務器，競對服務器，或者誰知道還有什么地方。當一個庫需要我們沒有的權限時，那問題就更大了。

同樣，一個系統的安全取決于其最薄弱的環節，但如果其中包含未經審核的代碼，那么你就不知道它到底有多安全。你精心設計的安全編碼實踐可能會被一個行為不當的庫所破壞。蘋果和谷歌實施的任何政策都是如此，例如“你不得對用戶追蹤”。

減少風險

當對一個庫（是否）進行使用評估時，我們首先要問幾個問題，以了解對庫的需求。

我們內部能做么？

有時候我們只需要簡單的粘貼復制真正需要的部分。在更復雜的場景中，庫與自定義后端通信，我們對該API進行了逆向，并自己構建了一個迷你SDK（同樣，只構建了我們需要的部分）。在90%的情況下，這是首選，但在與非常特定的供應商或需求集成時并不總是可行。

有多少用戶從該庫中受益？

在一種情況下，我們正在考慮添加一個風險很大的庫（根據下面的標準），旨在為一小部分用戶提供服務，同時將我們的所有用戶都暴露在該庫中。對于我們認為會從中受益的一小部分客戶，我們冒了為我們所有用戶帶來問題的風險。

這個庫有什么傳遞依賴？

我們還需要評估庫的所有依賴項的以下標準。

退出標準是什么？

如果集成成功，是否有辦法將其轉移到內部？如果不成功，是否有辦法刪除？

評價標準

如果此時團隊仍然希望集成庫，我們要求他們根據一組標準對庫進行“評分”。下面的列表并不全面，但應該能很好地說明我們希望看到的。

阻斷標準

這些標準將阻止我們從技術上或者公司政策上集成此庫，在進行下一步之前，我們必須解決：

過高的 deployment target/target SDKs。 我們支持過去4年主流的操作系統（版本），所以第三方庫至少也需要支持一樣多。

許可證不正確/缺失。 我們將許可文件與應用捆綁在一起，以確保我們可以合法使用代碼并將其歸屬于許可持有人。

沒有沖突的傳遞依賴關系。 一個庫不能有一個我們已經包含但版本不同的傳遞依賴項。

不顯示它自己的 UI 。 我們非常小心地使我們的產品看起來盡可能統一，定制用戶界面對此不利。

它不使用私有 API 。 我們不愿意冒 app 因使用私有 API 而被拒絕的風險。

主要關注點

閉源。 訪問源代碼意味著我們可以選擇我們想要包含的庫的哪些部分，以及如何將該源代碼與應用程序的其余部分捆綁在一起。對于我們來說，一個封閉源代碼的二進制發行版更難集成。

編譯時有警告。 我們啟用了“警告視為錯誤”，具有編譯警告的庫是庫整體質量（下降）的良好指示。

糟糕的文檔。 我們希望有高質量的內聯文檔，外部”如何使用“文檔，以及有意義的更新日志。

二進制體積。 這個庫有多大？一些庫提供了很多功能，而我們只需要其中的一小部分。尤其是在沒有訪問源碼權限的情況下，這通常是一個全有或全無的情況。

外部的網絡流量。 與我們無法控制的上游服務器/端點通信的庫可能會在服務器關閉、錯誤數據被發回等時關閉整個應用程序。這也與我上面提到的隱私問題相同。

技術支持。 當事情不能正常工作時，我們需要能夠報告/上報問題，并在合理的時間內解決問題。開源項目通常由志愿者維護，也很難有一個時間線，但至少我們可以自己進行修改。這在閉源項目是不可能的。

無法禁用。 雖然大多數庫特別要求我們初始化它，但有些庫在實例化時更“主動”，并且在我們不調用它的情況下可以自己執行工作。這意味著當庫導致問題時，我們無法通過功能變量或其他機制將其關閉。

我們為所有這些（和其他一些）標準分配了點數，并要求工程師為他們想要集成的庫匯總這些點數。雖然默認情況下，低分數并不難被拒絕，但我們通常會要求更多的理由來繼續前進。

最后

雖然這個過程看起來非常嚴格，在許多情況下，潛在風險是假設的，但我們有我在這篇博文中描述的每個場景的實際例子。將評估記錄下來并公開，也有助于將相對風險傳達給不熟悉移動平臺工作方式的人，并證明我們沒有隨意評估風險。

此外，我不想聲稱每一個第三方庫本質上都是壞的。事實上，我們在Lyft使用了很多：RxSwift和RxJava、Bugsnag的SDK、Google Maps、Tensorflow，以及一些較小的用于非常特定的用例。但所有這些要么都經過了充分審查，要么我們已經決定風險值得收益，同時對這些風險和收益的真正含義有了清晰的認識。

最后，作為一個專業開發人員提示：始終在庫的API之上創建自己的抽象，不要直接調用它們的API。這使得將來替換（或刪除）底層庫更加容易，再次減輕了與長期開發相關的一些風險。