關于使用第三方庫、代碼複用的一些思考

不管是<code>不要重複造輪子</code>，還是<code>站在巨人的肩膀上</code>，對于軟體開發來說，代碼複用都是最基本的原則之一。

代碼複用，可能是DRY（dont repeat yourself），也可能是使用别人的代碼，或者是開源項目，或者是其他團隊提供的元件、服務，或者是團隊内他人實作的公共子產品，這些複用大大減少了項目的開發周期和成本。

但怎樣才算是高效、正确的第三方代碼使用姿勢呢？在實操中，也會出現一些使用第三方代碼導緻失控的情況，比如使用了一些第三方代碼，但年久失修，當線上事故貌似與第三方代碼有關時，無法快速定位、解決問題。

本文是閱讀《clean code》的第八章<code>邊界（Boundaries）</code>時的一些思考。

本文位址：https://www.cnblogs.com/xybaby/p/11372846.html

本文将複用的代碼分為兩類：

一類是團隊外的代碼，具體指第三方庫、開源庫、公司内其他團隊的通用元件，其特征是，這樣的代碼往往需要做的比較通用，大而全；項目團隊隻是使用者，很難從根本上影響其設計或實作。

另一類則是團隊内的代碼，即項目團隊成員自行封裝的一些通用子產品、通用元件，其特征是核心為項目服務，比較友善協商修改。

這裡的複用，不局限于代碼，也包括可供遠端調用的服務。一般來說，項目會調研、選擇一些開源架構，也會使用公司内基礎服務部門或者雲計算上的一些服務，我覺得這都算複用。

最小化、集中化代碼複用

第三方庫往往追求功能（服務）的普适性，這樣代碼就能在多個環境中工作，吸引更多的使用者。而使用者往往隻需要滿足特定需求的部分接口，對于不需要的功能(以及不建議的使用方式)，對項目來說反而是負擔，控制不當反而會帶來風險。

比如redis，既能做記憶體資料庫，也能持久化；既支援單點部署，也能通過sentinel、cluster提供高可用以及水準擴充；而且還支援pub-sub（以及比較新的stream）。但在我們的項目中，隻用來記憶體緩存，而且對可用性、伸縮性也沒有太大需求。

原則上，使用第三方庫時，使用到的接口（服務）越少越好，将其封裝到單獨的檔案（類、子產品），在其他地方不能直接使用第三方庫。通過适配，隻将需要的部分功能納入，不需要的功能（接口）不要暴露出來。

這樣的好處在于入口統一，将所有對第三方庫的使用集中到最少量的代碼裡面，便于維護。同時，這也是分層的思想，将業務代碼與第三方庫解耦合，便于替換實作。

learning tests

要将一個開源項目引入自己的業務代碼，需要進行科學的調研和完備的測試。調研包括但不限于：與業務需求的重合度，開源社群的成熟度、活躍度等。而測試應包含以下幾個方面

功能測試

性能測試

壓力測試

故障測試

前兩項是最基礎的測試，主要判斷是第三方庫是否符合業務的功能、性能要求，同時掌握正确的使用姿勢。而後兩者，則常常是第三方庫以單獨的服務部署運作時的測試要點。

為了進行測試，我們會有一些測試代碼，也許會參考項目自帶的unittest、 code sample、tutorial、benchmark。但問題在于，這樣的測試代碼經常用完就扔，這樣導緻

如果後面出現問題，我們就需要不斷調試，來确定是類庫本身的問題，還是我們使用姿勢的問題。

當地三方庫更新之後，應用不敢跟着更新，因為沒有手段保證新版本的類庫提供了同等契約。

第二個問題我想很多很多人都會遇到，當依賴的第三方庫更新的時候，項目是否跟着一起更新你？兩種比較極端的政策我都遇到過，一種是始終更新到第三方庫的最新穩定版本；另一種是基本不更新，自己維護某個特定版本。

<code>learning test</code>能解決上述的第二個問題：

我們将所有的測試整理為一整套針對所使用的功能的單元測試，這些測試覆寫了我們對功能、性能、穩定性都諸多方面的需求。當第三方類庫的版本更新的時候，我們隻要把單元測試再跑一遍，就可以判斷新代碼的代碼是否提供了同等的契約，也就可以比較安全的進行更新。

不難看到，上一小節，“集中化第三方代碼使用”是<code>learning test</code>的基礎，讓我們很清楚的知道應該對哪些接口進行測試，如果要擴充對第三方庫的使用，也能很友善的增加、維護對應的測試。

在團隊内，也是非常鼓勵代碼的複用，比較常見的方式是形成各種通用的元件。那麼，如果程式員A使用了程式員B提供的公共子產品出了問題，那麼責任該如何劃分？

如果是開源代碼，毫無疑問隻能責怪使用者，但是在團隊中，似乎并不能完全歸咎于使用者。公共元件的使用者一般并不會對使用進行完整的測試，也會認為，“都是一個團隊的，就應該提供者保證品質，友善快速使用”。

我認為，使用者的責任占主要，使用者應該就使用方式進行測試，如果提供者已經提供了相應的單元測試，而且能通過，那麼就可以直接使用。否則應該添加對應的測試case，如果無法通過，則可以找提供者協商解決。對于通用子產品、通用元件的提供者，也應該有義務提供高覆寫率的單元測試，一來開發的時候因為本身就會測試，并不會增加額外的工作量；二來是對使用者的一份正式的保證，也能增加自己在團隊的影響力。

本文版權歸作者xybaby（博文位址：http://www.cnblogs.com/xybaby/）所有，歡迎轉載和商用，請在文章頁面明顯位置給出原文連結并保留此段聲明，否則保留追究法律責任的權利，其他事項，可留言咨詢。