純粹看到這方面的討論,所以寫一下個人心得
有經驗的開發者大概都已經有一定的體會
在我剛入門的時候滿願意嘗試各種 Library
有別人造好的輪子,那幹嘛再自己打造一個呢?
而且別人已經實現的功能看起來很強大、很好用,玩起來也很有趣
只是開源 Library當然不完全是這麼方便,使用前可以考慮以下理由
1.使用的語言及版本
你要引入的函式庫可能會使用其他語言或是不同的版本
需要承擔與當前的dependency衝突或造成日後版本升級的dependency衝突問題
2.需求不完全一致
你所需要的可能只是開源函式庫的一部分功能
但是他設計的API可能為因應廣泛的功能開發而需要更多的輸入
所以你可能會需要提供原本根本不用產生的資料
3.肥大
很多強大的框架、函式庫伴隨而來的是他的體積或是對資源的佔用
如果你開發的是與網路狀況關係更密切的應用,那麼更該盡量縮減應用的大小
4.維護與資安問題
日後你可能會因為效能、bug、配合其他功能所需的dependency等理由升級
這些也是採用上隱含的成本
這概念跟使用商用軟體或開源軟體的議題雷同
雖然開源軟體是很好的概念,也沒什麼帳面費用,但它隱含的成本可能不少於商用軟體
很多時候如果碰上bug,你可能得幫忙回報、修改才得以克服
有經驗的開發者大概都已經有一定的體會
在我剛入門的時候滿願意嘗試各種 Library
有別人造好的輪子,那幹嘛再自己打造一個呢?
而且別人已經實現的功能看起來很強大、很好用,玩起來也很有趣
只是開源 Library當然不完全是這麼方便,使用前可以考慮以下理由
1.使用的語言及版本
你要引入的函式庫可能會使用其他語言或是不同的版本
需要承擔與當前的dependency衝突或造成日後版本升級的dependency衝突問題
2.需求不完全一致
你所需要的可能只是開源函式庫的一部分功能
但是他設計的API可能為因應廣泛的功能開發而需要更多的輸入
所以你可能會需要提供原本根本不用產生的資料
3.肥大
很多強大的框架、函式庫伴隨而來的是他的體積或是對資源的佔用
如果你開發的是與網路狀況關係更密切的應用,那麼更該盡量縮減應用的大小
4.維護與資安問題
日後你可能會因為效能、bug、配合其他功能所需的dependency等理由升級
這些也是採用上隱含的成本
這概念跟使用商用軟體或開源軟體的議題雷同
雖然開源軟體是很好的概念,也沒什麼帳面費用,但它隱含的成本可能不少於商用軟體
很多時候如果碰上bug,你可能得幫忙回報、修改才得以克服
當然這也開源軟體能持續進步的精神
商用軟體就是把上述的問題丟給開發公司負責,由他們提出解決方案
所以沒有哪邊一定比較好,重點還是開發時的各種考量
商用軟體就是把上述的問題丟給開發公司負責,由他們提出解決方案
所以沒有哪邊一定比較好,重點還是開發時的各種考量
另外資安問題也是得重視的問題
left-pad事件也是頻傳的狀況
業餘時間開發的維護者不爽無法從採用的大公司分到收益時有所聞
當你發現重要的產品壞掉竟然是採用的open source層層倚賴的如此簡單的功能出問題
想必也是無言吧
Log4Shell漏洞也是源自於圖方便的極少數需求而來的
簡單講考量須回歸SOLID原則
你採用的方案是否會造成高耦合,難以抽換或引入困難的變更成本
推。
回覆刪除