评估Ruby

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

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

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

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

这种记录可以从知名作者那儿获得一些，他们很多都是在别的领域造诣颇深的人，却被Ruby所吸引，因为Ruby让他们觉得如虎添翼，这些人包括“用本双雄”（ PragDave和 //ndy）、 Justin Gehtland、 Bruce Tate、 David 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持越来越肯定的态度。