開源項(xiàng)目，這樣使用才穩(wěn)
一、前言
在公司的項(xiàng)目中，或多或少都會(huì)使用到一些開源的項(xiàng)目。但是在開源項(xiàng)目的選擇上，就需要格外的慎重了。
如果只是個(gè)人處于學(xué)習(xí)或者練手的目的，使用的一些比較新穎的開源項(xiàng)目，這個(gè)完全隨自己，想怎么使用就怎么使用。但是如果是在公司的商業(yè)項(xiàng)目上，就需要格外慎重了，因?yàn)樯虡I(yè)項(xiàng)目***個(gè)重點(diǎn)要求，就是一定要能保證穩(wěn)定。
本篇文章，就如何選擇在商業(yè)項(xiàng)目中使用的開源庫，做一個(gè)介紹。
二、正確的使用開源項(xiàng)目
2.1 使用成熟穩(wěn)定的開源項(xiàng)目
既然商業(yè)項(xiàng)目，主要是以穩(wěn)定為主，那么在選擇開源項(xiàng)目上，就需要以成熟穩(wěn)定為前提條件。
對(duì)于一些常用的技術(shù)，就那么多種類，網(wǎng)絡(luò)請(qǐng)求、ORM、圖片加載等。找一些明星項(xiàng)目，總是不會(huì)錯(cuò)的，這個(gè)相信大家都懂。
那么，正常來說，如何選擇一個(gè)相對(duì)穩(wěn)定的開源項(xiàng)目呢?
1、Github 上的熱度
一個(gè)開源項(xiàng)目，在 Github 上的 Start 數(shù)和 Fork 數(shù)，就可以從側(cè)面反應(yīng)出它的熱度。
2、issues 和***更新時(shí)間
一個(gè)開源項(xiàng)目的 issues ，可以表達(dá)很多正在使用它的人碰到的問題，以及作者的回復(fù)和有沒有得到解決。當(dāng)然，作者回復(fù)的速度和比例也是一個(gè)參考。
而***更新時(shí)間也反應(yīng)出這個(gè)項(xiàng)目是否有人在積極維護(hù)。
3、正在使用它的商業(yè)項(xiàng)目
一個(gè)優(yōu)秀的開源項(xiàng)目，注定不是你首先發(fā)現(xiàn)的。在你考慮是否將其集成到公司的商業(yè)項(xiàng)目的時(shí)候，一定也有其他人如此考慮了。所以有什么公司的項(xiàng)目，正在使用它，也是一個(gè)穩(wěn)不穩(wěn)定的標(biāo)識(shí)。
4、使用穩(wěn)定版本
Github 上的開源項(xiàng)目，也是在不停的維護(hù)和改進(jìn)迭代的，所以如果需要使用，一定要使用它打了 Tag 標(biāo)簽的版本，這樣才能***限度的保持穩(wěn)定可用。
5、開源協(xié)議
并非所有的開源項(xiàng)目都是可以隨便使用的。在使用前一定要閱讀開源許可協(xié)議，看它是否能允許你隨便使用在商業(yè)項(xiàng)目中。
不過 Github 上的開源項(xiàng)目，大多數(shù)限制并不嚴(yán)格。除了 GPL 協(xié)議需要額外注意，它規(guī)定使用它的項(xiàng)目也必須遵循 GPL 協(xié)議，也就是也必須開源，這肯定不適用商業(yè)項(xiàng)目。
2.2 了解背后的原理
如果決定使用這個(gè)開源項(xiàng)目，一定要理解其原理，這個(gè)其實(shí)在實(shí)際開發(fā)開發(fā)中，你修改一段別人維護(hù)的代碼，也需要結(jié)合上下文，理解它代碼的原理和邏輯，才能保證修改它不會(huì)引發(fā)其他的問題。
使用開源項(xiàng)目也正是如此，僅僅會(huì)用它是不夠的，決定是否將它引入的人，一定要對(duì)它的原理有足夠的了解，不能僅僅停留在 API 的使用上。
在使用前，扒開源碼看本質(zhì)，不是說一定要事無巨細(xì)的了解它所有的細(xì)節(jié)，但是主體的業(yè)務(wù)線，原理是什么，使用中需要注意什么，在什么場(chǎng)景下可能會(huì)出現(xiàn)問題。這些都是需要了解清楚的，避免出現(xiàn)問題而措手不及。
2.3 不要改動(dòng)源碼
大多數(shù)情況下，開源項(xiàng)目不可能永遠(yuǎn)滿足我們的需求，有時(shí)候我們可能需要對(duì)開源項(xiàng)目進(jìn)行一些定制修改。
那么，***是對(duì)其進(jìn)行擴(kuò)展而不是直接去修改它的源碼。
對(duì)于一些真正的明星開源項(xiàng)目，實(shí)際上已經(jīng)設(shè)計(jì)封裝的很好了，如果想要擴(kuò)展，也非常的簡單。例如，OkHttp，如果你在請(qǐng)求響應(yīng)的時(shí)候想做一些額外的操作，只需要增加一個(gè)攔截器即可。
而不改動(dòng)源碼的原因也非常的簡單，開源項(xiàng)目一般都是會(huì)持續(xù)維護(hù)和更新的，在不修改源碼的情況下，之后再進(jìn)行升級(jí)就非常的簡單，這里也推薦直接使用 Gradle 遠(yuǎn)程依賴的方式去集成(一定要明確指定版本號(hào))，這樣大多數(shù)情況下，升級(jí)基本上就是改一個(gè)版本號(hào)的事情。可也不排除會(huì)有接口上的變動(dòng)，但是一般這樣的變動(dòng)，也會(huì)提供升級(jí)指南之類的幫助文檔。
2.4 視情況決定引入方式
有時(shí)候需要的一些小的開源項(xiàng)目，并非功能強(qiáng)大的明星項(xiàng)目，可能只是一個(gè) UI 效果。
一些開源項(xiàng)目，為了功能上的大而全，可能會(huì)集成一些我們不需要的額外功能。而假如我們需要的只是這個(gè)開源項(xiàng)目中，很小的一部分，其實(shí)是可以考慮將其相關(guān)代碼類拷貝出來，單獨(dú)維護(hù)的。
這個(gè)的前提是此開源項(xiàng)目的耦合性太高了，導(dǎo)致內(nèi)部太多的類相互引用，這樣的情況下，我們只需要將我們關(guān)注的代碼拷貝出來，進(jìn)行簡單的修改解耦，即可直接使用。這樣的方式可以適當(dāng)減少方法數(shù)和 dex 的大小。
而如果開源項(xiàng)目本身耦合并不嚴(yán)重，實(shí)際上依然推薦使用 Gradle 遠(yuǎn)程依賴的方式引入，在最終打包的時(shí)候，只需要開啟 shrinkResources 即可，它會(huì)將一些項(xiàng)目內(nèi)沒有用到的資源移除掉，從而不用擔(dān)心方法數(shù)和安裝包大小的問題。
2.5 使用前需要進(jìn)行封裝
優(yōu)秀的開源項(xiàng)目，其實(shí)已經(jīng)封裝的非常好了，可能最終到使用者這邊，只需要一行代碼即可搞定。
但是哪怕是再好的封裝，我依然建議在使用前對(duì)其進(jìn)行一層封裝，哪怕是最簡單的封裝也可以。
對(duì)開源庫進(jìn)行封裝后使用，一個(gè)根本性的好處就是，接口統(tǒng)一。哪怕有一天，隨著業(yè)務(wù)的增長或者技術(shù)的迭代，之前的開源庫已經(jīng)沒有辦法滿足現(xiàn)在的需求了，需要對(duì)整個(gè)項(xiàng)目的該庫進(jìn)行替換。這個(gè)時(shí)候如果有一層封裝，那么替換起來只需要修改業(yè)務(wù)的接口實(shí)現(xiàn)類即可，而不是需要整個(gè)項(xiàng)目進(jìn)行代碼替換。
有些人可能會(huì)想了，我接手這個(gè)項(xiàng)目的時(shí)候，前人已經(jīng)是在直接使用這個(gè)開源項(xiàng)目了，現(xiàn)在我需要替換它，不是依然需要全文進(jìn)行代碼替換嗎?
這樣的問題其實(shí)非常的常見，那么如果遇上這樣的問題，實(shí)際上我們既然已經(jīng)要移除它了，完全可以在項(xiàng)目內(nèi)建立與它包名類名都相同的同名類文件，然后根據(jù)它對(duì)外的接口，去實(shí)現(xiàn)它。這樣我們只需要處理兩個(gè)庫之間，接口使用的差異即可，其實(shí)也可以達(dá)到快速替換的效果。
但是，也有人說了，這樣是不是就可以不封裝了?反正最終替換的時(shí)候，處理兩個(gè)庫接口的差異即可。其實(shí)并不是這樣的，提前封裝是為了更優(yōu)雅更從容的替換，有時(shí)候不同庫的使用方式，去處理它們的差異會(huì)讓我們的代碼非常的混亂和不可讀。就像在修改之前，自己給自己制定了一系列的規(guī)則去束縛自己一樣，所以提前封裝，把規(guī)則掌控在自己手里。
所以，如果可以，封裝一層再進(jìn)行使用。
2.6 實(shí)時(shí)關(guān)注更新
開源項(xiàng)目必然是會(huì)保持更新的，在使用過程中，如果碰到問題，可以去看看最近的提交以及 issues，看看有沒人碰到與你相同的問題，或者可能你的問題已經(jīng)在***版得到解決。
三、結(jié)語
在商業(yè)項(xiàng)目中，使用那個(gè)開源項(xiàng)目大多數(shù)情況下都是項(xiàng)目 Leader 去決定的，但是這并不影響我們了解自己維護(hù)的項(xiàng)目中，使用到的開源項(xiàng)目，不僅更有利于我們?cè)诠ぷ髦懈焖俚陌l(fā)現(xiàn)問題。閱讀優(yōu)秀的開源項(xiàng)目，是提高技術(shù)能力非?？斓囊粋€(gè)手段。
【本文為51CTO專欄作者“張旸”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過微信公眾號(hào)聯(lián)系作者獲取授權(quán)】
