不管是不要重復(fù)造輪子，還是站在巨人的肩膀上，對于軟件開發(fā)來說，代碼復(fù)用都是最基本的原則之一。

代碼復(fù)用，可能是DRY（dont repeat
yourself），也可能是使用別人的代碼，或者是開源項目，或者是其他團(tuán)隊提供的組件、服務(wù)，或者是團(tuán)隊內(nèi)他人實現(xiàn)的公共模塊，這些復(fù)用大大減少了項目的開發(fā)周期和成本。


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

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

本文地址：https://www.cnblogs.com/xybaby/p/11372846.html
<https://www.cnblogs.com/xybaby/p/11372846.html>

本文將復(fù)用的代碼分為兩類：

*
一類是團(tuán)隊外的代碼，具體指第三方庫、開源庫、公司內(nèi)其他團(tuán)隊的通用組件，其特征是，這樣的代碼往往需要做的比較通用，大而全；項目團(tuán)隊只是使用者，很難從根本上影響其設(shè)計或?qū)崿F(xiàn)。
* 另一類則是團(tuán)隊內(nèi)的代碼，即項目團(tuán)隊成員自行封裝的一些通用模塊、通用組件，其特征是核心為項目服務(wù)，比較方便協(xié)商修改。
如何復(fù)用第三方庫代碼


這里的復(fù)用，不局限于代碼，也包括可供遠(yuǎn)程調(diào)用的服務(wù)。一般來說，項目會調(diào)研、選擇一些開源框架，也會使用公司內(nèi)基礎(chǔ)服務(wù)部門或者云計算上的一些服務(wù)，我覺得這都算復(fù)用。

最小化、集中化代碼復(fù)用


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


比如redis，既能做內(nèi)存數(shù)據(jù)庫，也能持久化；既支持單點(diǎn)部署，也能通過sentinel、cluster提供高可用以及水平擴(kuò)展；而且還支持pub-sub（以及比較新的stream）。但在我們的項目中，只用來內(nèi)存緩存，而且對可用性、伸縮性也沒有太大需求。


原則上，使用第三方庫時，使用到的接口（服務(wù)）越少越好，將其封裝到單獨(dú)的文件（類、模塊），在其他地方不能直接使用第三方庫。通過適配，只將需要的部分功能納入，不需要的功能（接口）不要暴露出來。

這樣的好處在于入口統(tǒng)一，將所有對第三方庫的使用集中到最少量的代碼里面，便于維護(hù)。同時，這也是分層的思想，將業(yè)務(wù)代碼與第三方庫解耦合，便于替換實現(xiàn)。

learning tests

要將一個開源項目引入自己的業(yè)務(wù)代碼，需要進(jìn)行科學(xué)的調(diào)研和完備的測試。調(diào)研包括但不限于：與業(yè)務(wù)需求的重合度，開源社區(qū)的成熟度、活躍度等。而測試應(yīng)包含以下幾個方面

* 功能測試
* 性能測試
* 壓力測試
* 故障測試
前兩項是最基礎(chǔ)的測試，主要判斷是第三方庫是否符合業(yè)務(wù)的功能、性能要求，同時掌握正確的使用姿勢。而后兩者，則常常是第三方庫以單獨(dú)的服務(wù)部署運(yùn)行時的測試要點(diǎn)。

為了進(jìn)行測試，我們會有一些測試代碼，也許會參考項目自帶的unittest、 code
sample、tutorial、benchmark。但問題在于，這樣的測試代碼經(jīng)常用完就扔，這樣導(dǎo)致

* 如果后面出現(xiàn)問題，我們就需要不斷調(diào)試，來確定是類庫本身的問題，還是我們使用姿勢的問題。
* 當(dāng)?shù)厝綆焐壷?，?yīng)用不敢跟著升級，因為沒有手段保證新版本的類庫提供了同等契約。

第二個問題我想很多很多人都會遇到，當(dāng)依賴的第三方庫升級的時候，項目是否跟著一起升級你？兩種比較極端的策略我都遇到過，一種是始終更新到第三方庫的最新穩(wěn)定版本；另一種是基本不升級，自己維護(hù)某個特定版本。

learning test能解決上述的第二個問題：


我們將所有的測試整理為一整套針對所使用的功能的單元測試，這些測試覆蓋了我們對功能、性能、穩(wěn)定性都諸多方面的需求。當(dāng)?shù)谌筋悗斓陌姹靖碌臅r候，我們只要把單元測試再跑一遍，就可以判斷新代碼的代碼是否提供了同等的契約，也就可以比較安全的進(jìn)行升級。

不難看到，上一小節(jié)，“集中化第三方代碼使用”是learning test
的基礎(chǔ)，讓我們很清楚的知道應(yīng)該對哪些接口進(jìn)行測試，如果要擴(kuò)展對第三方庫的使用，也能很方便的增加、維護(hù)對應(yīng)的測試。

如何復(fù)用團(tuán)隊內(nèi)的代碼

在團(tuán)隊內(nèi)，也是非常鼓勵代碼的復(fù)用，比較常見的方式是形成各種通用的組件。那么，如果程序員A使用了程序員B提供的公共模塊出了問題，那么責(zé)任該如何劃分？


如果是開源代碼，毫無疑問只能責(zé)怪使用者，但是在團(tuán)隊中，似乎并不能完全歸咎于使用者。公共組件的使用者一般并不會對使用進(jìn)行完整的測試，也會認(rèn)為，“都是一個團(tuán)隊的，就應(yīng)該提供者保證質(zhì)量，方便快速使用”。


我認(rèn)為，使用者的責(zé)任占主要，使用者應(yīng)該就使用方式進(jìn)行測試，如果提供者已經(jīng)提供了相應(yīng)的單元測試，而且能通過，那么就可以直接使用。否則應(yīng)該添加對應(yīng)的測試case，如果無法通過，則可以找提供者協(xié)商解決。對于通用模塊、通用組件的提供者，也應(yīng)該有義務(wù)提供高覆蓋率的單元測試，一來開發(fā)的時候因為本身就會測試，并不會增加額外的工作量；二來是對使用者的一份正式的保證，也能增加自己在團(tuán)隊的影響力。

• ? 上一篇：.NetCore從零開始使用Skywalking分布式鏈路追蹤系統(tǒng)
• ? 下一篇：上周熱點(diǎn)回顧（7.29-8.4）