推 asoedarren:推~ 02/15 20:57
推 PsMonkey:可以借轉 Java 版嗎？ 02/16 06:35
推 tomex:轉java版會被打吧 :) 大家各有不同的角度去看待而己 02/16 10:15
推 euleramon:值得推薦 02/17 10:39
評估程式開發元件的選擇策略
===========================
我們會使用元件，最主要的是想站在別人肩膀上來看更遠的世界，
更是不想選擇徒手鑄車輪的下下策，開發時間及生產力是很重要的。
由於是應用別人的技術而己，因此選擇一個真正"對"的元件很重要，
否則投資心力於錯的元件，不僅費時，更會無法與未來接軌。
就某功能而言，網路上一定會出現很多功能類似的元件
使用者常常面臨惶恐不知如何選擇的困境。
個人依據多年的軟體/元件等試用心得，歸納出以下幾項評選的策略:
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