關于引入開源技術的一些建議

序言

在産品研發過程中，經常有一些所需的基礎元件子產品，推測有一定的通用性，于是我們會考慮引入一些開源技術。此時如何引入就需要一些注意點，包括：

（1）對開源技術的可用性負責

開源技術引入系統後，屬于系統的一部分，自此你需要對它的可用性負責。需要将這些代碼當做自己的代碼管理起來，包括源碼、依賴庫、元件包、相關文檔等。開源技術社群是不做任何可用性的承諾的。

（2）開源技術的技術成熟度

開源技術的起因千差萬别，其發展曆程更是各有各的故事。開源隻是代碼公開，提供了一種利用群衆的力量來發現問題、解決問題的能力，但是否能轉換為實際，真的很難。對于普通開源技術，更多的價值是提供了一種設計參考，一種技術疊代的基礎。

（3）許可授權的範圍

開源不等于免費，不同的授權，不同的使用方案。開源領域的授權協定五花八門，即使你仔細研究半天，也未必能了解，它最終是怎麼授權你使用。如果你開發的是商業軟體，則需要注意一下，避免不必要的麻煩。

引入開源技術的 4 個階段

這裡提供一些思路，以抛磚引玉。

階段 1：技術選型

此階段為粗篩，去掉一些明顯有風險的選型，以便下一步能聚焦在更有價值的候選項上。每個組織的的選型要求不同，但事先确定一些标準，然後針對候選項逐一評估，會讓選型更有條理、更可靠。如

選型标準	GitHub star數	版本釋出周期	社群活躍度	開發語言	依賴庫分析	文檔可用性	授權協定	應用案例	第三方評測資料
方案1	……
方案2
方案3

階段 2：技術實測

在初步選型後，需要實際測試的範圍就縮小很多。這時需要從自己的應用場景中，抽象出一組測試場景，并驗證其可用性。包括：

• 開發難易：上手實際寫一下，便于掌握使用的複雜度。
• 場景支援度：不需要全，但需要有代表性；不需要真接入系統，模拟測試即可。
• 性能：不同負載下的性能表現，0.5x、1.0x、1.2x、1.5x……
• 穩定性：給定負載下的，穩定運作結果，包括是否當機，記憶體是否正常等。

階段 3：工程應用

場景一：多人協作時

現代軟體更多是多人協作開發，在引入新的開源技術後，需要将其引入到團隊中，避免一下導緻其他夥伴都編譯失敗，各種抱怨。如果不需要他人關注，則做好隔離設計即可。

場景二：基礎元件的基礎化

通常使用基礎元件時，隻需要一次編譯釋出即可，後續簡單引入即可，即降低了編譯效率，也保證了元件的品質（重複編譯的結果不一定一緻）。

場景三：酌情融入到團隊的基礎設施中

例如團隊使用Maven來做包管理，則遵從團隊的工程實踐規則，将引入的開源技術的包管理起來，妥善解決由此引發的一些沖突問題。

階段 4：回饋社群

開源是一種技術精神，作為開發者，我們既要積極使用開源技術，同時也要基于自己的能力，積極将使用中問題、嘗試的改進回饋到社群，促進後續的版本解決自己的問題。