作者tomex (tomex_ou)
看板C_Sharp
标题[心得]评估程式开发元件的选择策略
时间Thu Feb 15 16:46:14 2007
评估程式开发元件的选择策略
===========================
我们会使用元件,最主要的是想站在别人肩膀上来看更远的世界,
更是不想选择徒手铸车轮的下下策,开发时间及生产力是很重要的。
由於是应用别人的技术而己,因此选择一个真正"对"的元件很重要,
否则投资心力於错的元件,不仅费时,更会无法与未来接轨。
就某功能而言,网路上一定会出现很多功能类似的元件
使用者常常面临惶恐不知如何选择的困境。
个人依据多年的软体/元件等试用心得,归纳出以下几项评选的策略:
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
1F:推 asoedarren:推~ 02/15 20:57
2F:推 PsMonkey:可以借转 Java 版吗? 02/16 06:35
3F:推 tomex:转java版会被打吧 :) 大家各有不同的角度去看待而己 02/16 10:15
4F:推 euleramon:值得推荐 02/17 10:39