[心得]評估程式開發元件的選擇策略

看板C_Sharp (C#)作者tomex (tomex_ou)時間18年前 (2007/02/15 16:46)推噓4(4推 0噓 0→)

留言4則, 4人參與討論串1/3 (看更多)

評估程式開發元件的選擇策略 =========================== 我們會使用元件，最主要的是想站在別人肩膀上來看更遠的世界，更是不想選擇徒手鑄車輪的下下策，開發時間及生產力是很重要的。由於是應用別人的技術而己，因此選擇一個真正"對"的元件很重要，否則投資心力於錯的元件，不僅費時，更會無法與未來接軌。就某功能而言，網路上一定會出現很多功能類似的元件使用者常常面臨惶恐不知如何選擇的困境。個人依據多年的軟體/元件等試用心得，歸納出以下幾項評選的策略: 1.作者是否持續更新? 更新的日期最好是在半年內。因為會停止開發產品，大多數是作者個人因素或是市場上出現更好的同質產品好的作者會公告原因，不好的作者什麼都不說須知作者開發產品很辛苦，但支持產品的Fans也很用心大家勾勒出一個美好的未來，Fans們也用心回報出bug及測試，不管結局如何，總是要有個好的ending，這評估要點是最重要的。 2.版本是否為1.x以上? 除了很嚴謹的知名元件外，好的元件不可能照教科書版本理論這樣慢慢磨凡是那種以0.0.x版開始的，90%都會半途而廢。 3.是否很多人使用或討論該元件? 在google鍵入該元件名稱，搜尋是否有很多人使用或常見問題。好的元件一定有許多人討論及介紹的。 4.元件命名及架構是否遵循風格? 所謂名不正言不順，元件的語法命名規則，若不遵守的語言風格者常常是其他言語行家中途轉入，這些作者大部分是玩票性質滿足實作他們想要的某一功能後，就不願再好好包製收尾至完整。他們也懶得為使用者的語法貼切去細細思考。例如用java風格命名的，他們是以java的角度去創作元件而忽略.Net用戶使用它們時的.Net思維。每個物件的命名其實很重要，不貼切的物件名稱，用起來特別蹩扭常使用的功能組合，只要稍微包一下，End User就少去很多贅碼「物必有屬」的OO概念，又何必以小寫字作Method名稱呢? 5.是否為Open Source? 商業元件通常作得比Open Source的還來得完整及貼心不過若能免費授權使用或收費少一點，是最好的。雖然成本是重要的考量，不過好的商業元件若在架構上很具未來性依然是要選擇商業元件的，因此free的要素並非絕對。 6.官方網站是否製作較完整? 通常細心的元件創作者，他會想好好介紹元件及功能，儘量愈短時間就能給User一個概念因此會花時間去維護其網站，很少是用純文字隨便打一打。一個良善元件，通通是擅於包裝整理的，因為將心比心的作者，會把這個心意不僅作在元件中，外在環境也一樣重要的。以上六個原則, 僅供參考。 Author: Tomex Ou -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.130.1.144