[請益] 如何決定要不要使用某個ThirdParty Library

看板Soft_Job作者 (沒有存在感的人)時間11年前 (2015/01/18 04:10), 11年前編輯推噓9(9推 0噓 38→)
留言47則, 9人參與, 最新討論串1/6 (看更多)
今天看到一個口試題目覺得很有趣，不知道業界的人對於這個問題怎麼看? 是說開發軟體的時候，要怎麼決定是不是要用某個Third Party Library 有幾點是在決定前需要對該library研究的： - 是否可靠？ - 是否跟其他library有相依性？ - 編譯的方式 - coding有沒做好？要如何確認？ - 可擴展性，可配置，可修改？ - 該library的優勢與劣勢？ - threading model如何？可擴展嗎？ - 最後，該library值得選用嗎？ 我希望能夠投身業界，可是我好像沒有仔細想過這些問題。 (之前寫小程式也沒仔細考慮過這些) 希望各位前輩能夠分享一下想法，讓我了解我想法跟實際業界的差距。 謝謝。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 90.27.97.212 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1421525445.A.3AF.html ※ 編輯: wtchen (90.27.97.212), 01/18/2015 04:11:51
→
01/18 04:52, , 1F
初步了解通常在 Library 網站簡介或火力展示能略知一
01/18 04:52, 1F
→
01/18 04:53, , 2F
二，接下來，你要先了解授權方式跟取得授權過程需要
01/18 04:53, 2F
→
01/18 04:53, , 3F
要多少費用
01/18 04:53, 3F
→
01/18 04:53, , 4F
會不會壓縮到產品利潤，會不會有致命的授權問題
01/18 04:53, 4F
→
01/18 04:53, , 5F
造成產品有法律層面問題無法出售，公司、公司客戶
01/18 04:53, 5F
→
01/18 04:53, , 6F
願不願意掏錢出來使用，都會影響你導入的過程
01/18 04:53, 6F
→
01/18 04:53, , 7F
簡單說，在充份被授權的情況下，
01/18 04:53, 7F
→
01/18 04:54, , 8F
你才有足夠的時間去對 Library「驗貨」
01/18 04:54, 8F
→
01/18 04:54, , 9F
檢測跟驗證的方法很多種，但有幾項幾乎是鐵則
01/18 04:54, 9F
→
01/18 04:54, , 10F
除了相關文件齊不齊，功能是否有效解決你產品問題
01/18 04:54, 10F
→
01/18 04:54, , 11F
還要考慮這個東西在某些平台上的壽命，能多久？
01/18 04:54, 11F
→
01/18 04:54, , 12F
未來會不會需要更換?
01/18 04:54, 12F
→
01/18 04:55, , 13F
有時候還要翻授權、版權聲明 留意廠商支援可到哪
01/18 04:55, 13F
→
01/18 04:55, , 14F
甚至龜毛一點，留意一下這間公司/團體賺不賺錢
01/18 04:55, 14F
→
01/18 04:55, , 15F
擔心突然中途斷了維護，之後你修他們 Code 又是一個
01/18 04:55, 15F
→
01/18 04:56, , 16F
大工程（例如在新平台支援某種功能、維持功能正常）
01/18 04:56, 16F
→
01/18 04:56, , 17F
若不行，可能連整個 Library 都得抽換掉。
01/18 04:56, 17F
→
01/18 04:57, , 18F
這個部分跟你用套件也是同樣道理
01/18 04:57, 18F
→
01/18 04:57, , 19F
另外，近期資訊安全大家比較講究
01/18 04:57, 19F
→
01/18 04:57, , 20F
你得檢查這個套件/Libary 會不會有奇怪的行為
01/18 04:57, 20F
→
01/18 04:57, , 21F
如果你公司能買斷原始碼看還比較方便點
01/18 04:57, 21F
→
01/18 04:57, , 22F
若沒有，為了對別人的保證（主管、客戶）使他們安心
01/18 04:57, 22F
→
01/18 04:58, , 23F
你還需要用一些網路、檔案、系統工具追蹤偵測一下
01/18 04:58, 23F
→
01/18 04:59, , 24F
對他們作記錄，了解這元件有沒有動其他的手腳後門
01/18 04:59, 24F
→
01/18 04:59, , 25F
總而言之，要顧慮的還蠻多的
01/18 04:59, 25F
→
01/18 05:00, , 26F
不過這些動作必須都在充分取得授權下進行才有意義
01/18 05:00, 26F
→
01/18 05:57, , 27F
原來業界優先考量的還是錢跟安全性...
01/18 05:57, 27F
→
01/18 05:58, , 28F
(雖然我好像也沒多驚訝啦)
01/18 05:58, 28F
→
01/18 05:58, , 29F
不過函式庫本身要怎麼觀察比較好呢？
01/18 05:58, 29F
→
01/18 05:59, , 30F
我想不出來關於執行緒跟軟體開發的關係(非本科出身)
01/18 05:59, 30F
→
01/18 06:53, , 31F
你可以使用第四方的library來檢測它的安全性XD
01/18 06:53, 31F
推
01/18 07:55, , 32F
thread-safe的問題？libc也有函式是不thread-safe的
01/18 07:55, 32F
推
01/18 08:03, , 33F
抱歉應該說POSIX的某些函數 http://goo.gl/JvNUcm
01/18 08:03, 33F
推
01/18 08:10, , 34F
實際去用，弄個壓力測試應該就能測出來了，但是通常會有
01/18 08:10, 34F
→
01/18 08:10, , 35F
文件說明這些東西吧？
01/18 08:10, 35F
推
01/18 08:17, , 36F
如果用的lib有不thread-safe的東西卻沒有文件強調，
01/18 08:17, 36F
→
01/18 08:17, , 37F
等踩到會很難找
01/18 08:17, 37F
推
01/18 09:19, , 38F
坦白說我有點看不懂原問題的〝Thread Model〞是指什麼
01/18 09:19, 38F
→
01/18 09:20, , 39F
thread model在系統層級來說是kernel thread跟user
01/18 09:20, 39F
→
01/18 09:20, , 40F
thread的mapping model，3rd party library應該普遍碰
01/18 09:20, 40F
→
01/18 09:21, , 41F
不到這層？還是想說程式自己maintain的thread pool?
01/18 09:21, 41F
推
01/18 12:53, , 42F
竟然沒考慮 Licensing 囧
01/18 12:53, 42F
推
01/18 14:20, , 43F
其實還會再考慮背後的開發社群活躍程度
01/18 14:20, 43F
推
01/18 18:57, , 44F
用thirdparty最重要的就是授權問題吧,其他都其次
01/18 18:57, 44F
推
01/19 00:40, , 45F
第一想到就是license
01/19 00:40, 45F
→
01/19 09:43, , 46F
其實發現沒有文件說明的時候~就要慎重考慮是否採用了~這
01/19 09:43, 46F
→
01/19 09:44, , 47F
如果沒有很多人用~通常表示還有很多雷等著你踩...
01/19 09:44, 47F
‣ 更多 wtchen 的文章
文章代碼(AID): #1Kki75El (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 6 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共6篇)
‣ 更多 wtchen 的文章
文章代碼(AID): #1Kki75El (Soft_Job)