评估Ruby


原文:EvaluatingRuby    ruby        2006年5月10日            Bliki 索引

既然你读到这篇文字,我猜你已经知道人们对Ruby这门编程语言吵得不可开交了,尤其是对Rails这个Web应用开发框架更是吵得一塌糊涂。有人说它是编程的未来,前途光明;有人说它是旁门左道,危险暗淡。

我是在几年前开始用Ruby的,当时用本主义引起了我的兴趣,Ruby很快成为我的首选脚本语言。随后,它逐渐接管了我个人网站大量的生成与维护工作——尤其是我的Bliki。这门语言真让我喜欢。

我自己喜欢用Ruby,我们的客户就也应该用吗——两件事距离甚远。但我们可以根据其特性评估它是否适合用来做客户的项目,这就引起对后边一堆东西好坏利弊的争论:动态类型、惯例重于配置(convention over configuration)、进程 VS 线程,等等。这些讨论有帮助,但我对此持审慎态度,因为只凭空争论无法判断的事情太多了——有些东西在高尔夫球课上听起来头头是道,但它们致使客户项目进展变慢让我们多投入的时间难道还少吗?所以,我做判断倾向于依据现实经验——要找到人们在主流环境下交付项目的跟踪记录,还有使用Ruby开发的记录。

这种记录可以从知名作者那儿获得一些,他们很多都是在别的领域造诣颇深的人,却被Ruby所吸引,因为Ruby让他们觉得如虎添翼,这些人包括“用本双雄”(PragDave//ndy)、Justin GehtlandBruce TateDavid Geary……这个名单足以证明Ruby值得一瞧了。但也许我喜欢偏袒自家人吧,一直以来我首先要听取的是ThoughtWorker们的说法,他们做过的事我了解,他们的项目我拿来做验核也更方便。

尽管“吃螃蟹”的历史刚开始不久,我已经可以根据好几个项目的经验做分析了,到目前为之,分析结果力挺Ruby。每次我问他们:“你觉得用Ruby 比用Java或C#生产力有显著提高吗?”我听到的无一例外都是一句有力的肯定:“是的!”这已足够让我开始断言:如果你的项目合适,应该给Ruby个机会。当然了,我没把什么算“合适”这个小问题说死。

这个问题要说一下,尽管一些项目(我不妨称之为典型的Web项目)用Rails做非常合适,被普遍认为是Rails绝佳的用武之地,但除此之外,Ruby的地盘还包括一些别的领土:
  • 用户通过触摸屏直接控制的亭内式设备,其UI是一个非常AJAX化的Web前端,Rails已经在那儿派上用场了。但除了UI,还包括各种通讯:硬件设备、加密、一些偏门儿的网络部件等——所有这些都基于一个类似Linux的应用。
  • 大量SQL操作的批处理——用Ruby描述清楚处理需求,得到的Ruby表达式被转换为SQL执行实际操作,再辅以少量的Rails功能实现前端——这种情况也不属于典型的Rails应用。
  • 有的项目在许多方面都与标准Web应用相似,但还包括大量其他方面的工作:从不同格式文件中提取并处理数据、(用Ploticus)绘制非常花哨的图片和表格。
参与过上述几种应用的人说,要是不选Ruby而用别的平台,他们搞定功能创造价值的速度不会那么快。听过之后我就想,如果你正在追求更快的交付速度和更强的生产力,你应该认真考查一下Ruby。

不过还有一些不确定的问题,尤其是到了项目后期强化阶段——特别出现团队人员变动的时候——会不会发生麻烦现在下结论还为时尚早。有人认为Ruby的动态特性以及工具的缺乏会导致问题,也有人认为Ruby一贯鼓励简单性,能弥补那些短处。这本来就是个无法准确预测的问题,只能等我掌握了更多材料才能告诉你。

Cedric Beust认为,尽管Ruby是一个出众的平台,但可能无法成为主流,他的论析入木三分,我完全理解他这个观点——和许多前Smalltalk开发者一样,我老早就明白优秀高产的平台可能成不了当前主流企业应用的首选。如果对你而言,重要的是只采用主流平台,那么你还得静观其变。不过,不囿于主流而获成功的案例也非常多。

还有许多项目,开发的生产率并不是首要的,取而代之的是政治及其他沟通上的因素。那样的话,Ruby的优势就被大大削减了。

总的来说,了解了这些来自我们值得信赖的同事们的切身经验,我对在注重速度、响应性以及生产力的严肃工作中使用Ruby持越来越肯定的态度。
发布了10 篇原创文章 · 获赞 0 · 访问量 40万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览