不管是不要重復造輪子，還是站在巨人的肩膀上，對於軟件開發來說，代碼復用都是最基本的原則之一。
代碼復用，可能是DRY（dont repeat yourself），也可能是使用別人的代碼，或者是開源項目，或者是其他團隊提供的組件、服務，或者是團隊內他人實現的公共模塊，這些復用大大減少了項目的開發周期和成本。
但怎樣才算是高效、正確的第三方代碼使用姿勢呢？在實操中，也會出現一些使用第三方代碼導致失控的情況，比如使用了一些第三方代碼，但年久失修，當線上事故貌似與第三方代碼有關時，無法快速定位、解決問題。
本文是閱讀《clean code》的第八章邊界（Boundaries）時的一些思考。
本文地址：https://www.cnblogs.com/xybaby/p/11372846.html
本文將復用的代碼分為兩類：
- 一類是團隊外的代碼，具體指第三方庫、開源庫、公司內其他團隊的通用組件，其特征是，這樣的代碼往往需要做的比較通用，大而全；項目團隊只是使用者，很難從根本上影響其設計或實現。
- 另一類則是團隊內的代碼，即項目團隊成員自行封裝的一些通用模塊、通用組件，其特征是核心為項目服務，比較方便協商修改。
如何復用第三方庫代碼
這里的復用，不局限於代碼，也包括可供遠程調用的服務。一般來說，項目會調研、選擇一些開源框架，也會使用公司內基礎服務部門或者雲計算上的一些服務，我覺得這都算復用。
最小化、集中化代碼復用
第三方庫往往追求功能（服務）的普適性，這樣代碼就能在多個環境中工作，吸引更多的用戶。而使用者往往只需要滿足特定需求的部分接口，對於不需要的功能(以及不建議的使用方式)，對項目來說反而是負擔，控制不當反而會帶來風險。
比如redis，既能做內存數據庫，也能持久化；既支持單點部署，也能通過sentinel、cluster提供高可用以及水平擴展；而且還支持pub-sub（以及比較新的stream）。但在我們的項目中，只用來內存緩存，而且對可用性、伸縮性也沒有太大需求。
原則上，使用第三方庫時，使用到的接口（服務）越少越好，將其封裝到單獨的文件（類、模塊），在其他地方不能直接使用第三方庫。通過適配，只將需要的部分功能納入，不需要的功能（接口）不要暴露出來。
這樣的好處在於入口統一，將所有對第三方庫的使用集中到最少量的代碼里面，便於維護。同時，這也是分層的思想，將業務代碼與第三方庫解耦合，便於替換實現。
learning tests
要將一個開源項目引入自己的業務代碼，需要進行科學的調研和完備的測試。調研包括但不限於：與業務需求的重合度，開源社區的成熟度、活躍度等。而測試應包含以下幾個方面
- 功能測試
- 性能測試
- 壓力測試
- 故障測試
前兩項是最基礎的測試，主要判斷是第三方庫是否符合業務的功能、性能要求，同時掌握正確的使用姿勢。而后兩者，則常常是第三方庫以單獨的服務部署運行時的測試要點。
為了進行測試，我們會有一些測試代碼，也許會參考項目自帶的unittest、 code sample、tutorial、benchmark。但問題在於，這樣的測試代碼經常用完就扔，這樣導致
- 如果后面出現問題，我們就需要不斷調試，來確定是類庫本身的問題，還是我們使用姿勢的問題。
- 當地三方庫升級之后，應用不敢跟着升級，因為沒有手段保證新版本的類庫提供了同等契約。
第二個問題我想很多很多人都會遇到，當依賴的第三方庫升級的時候，項目是否跟着一起升級你？兩種比較極端的策略我都遇到過，一種是始終更新到第三方庫的最新穩定版本；另一種是基本不升級，自己維護某個特定版本。
learning test能解決上述的第二個問題：
我們將所有的測試整理為一整套針對所使用的功能的單元測試，這些測試覆蓋了我們對功能、性能、穩定性都諸多方面的需求。當第三方類庫的版本更新的時候，我們只要把單元測試再跑一遍，就可以判斷新代碼的代碼是否提供了同等的契約，也就可以比較安全的進行升級。
不難看到，上一小節，“集中化第三方代碼使用”是learning test的基礎，讓我們很清楚的知道應該對哪些接口進行測試，如果要擴展對第三方庫的使用，也能很方便的增加、維護對應的測試。
如何復用團隊內的代碼
在團隊內，也是非常鼓勵代碼的復用，比較常見的方式是形成各種通用的組件。那么，如果程序員A使用了程序員B提供的公共模塊出了問題，那么責任該如何划分？
如果是開源代碼，毫無疑問只能責怪使用者，但是在團隊中，似乎並不能完全歸咎於使用者。公共組件的使用者一般並不會對使用進行完整的測試，也會認為，“都是一個團隊的，就應該提供者保證質量，方便快速使用”。
我認為，使用者的責任占主要，使用者應該就使用方式進行測試，如果提供者已經提供了相應的單元測試，而且能通過，那么就可以直接使用。否則應該添加對應的測試case，如果無法通過，則可以找提供者協商解決。對於通用模塊、通用組件的提供者，也應該有義務提供高覆蓋率的單元測試，一來開發的時候因為本身就會測試，並不會增加額外的工作量；二來是對使用者的一份正式的保證，也能增加自己在團隊的影響力。