Ruby与技术成熟度曲线模型

作者 Werner Schuster 译者 郑柯 发布于 2007年10月10日 上午1时42分

社区

Ruby

主题

性能和可伸缩性,

Ruby on Rails,

故事和案例分析

最近有一篇关于基于Rails的失败项目的博客文章，引发了一场激烈的辩论。可以预测，将赌注押在与Rails相竞争的技术上，将此作为Rails即将消逝的标志——特别是当这篇文章详细说明考虑重新使用php技术之后。不过，有些人仔细分析了文章中所说的内容。Austin Ziegler指出其实是一些非技术方面的问题导致了项目的失败：

他没有意识到现有的专家并不了解这门新技术。他和他的雇员们没有对Ruby有清醒的认识，也许出于这个原因，他们不能深入掌握如何使用Ruby。这种情形下，并不是专家来判断某项技术是否合适，而是由管理层来考虑这项技术能否合用（很抱歉Derek，也许你现在还在亲自写代码，但你更应该适应管理者的角色）。

上面的话指出了这样的事实：该公司的软件都是基于PHP的，所有的开发人员都从事PHP开发。一个完全仰仗PHP开发的软件公司，使用Ruby on Rails重写软件，产生问题是必然的。更特别要指出的是，原博客文章中明确写道，公司只有一个全职Rails开发人员，此外再加上博客文章的作者；而且作者明确表明他更喜欢使用PHP工作，并且公司的其他开发人员以及公司的软件都是基于PHP的。

Austin指出的另外一个问题是：这个项目是针对现有软件进行重新开发。

Derek执行这个项目的方式，是希望自下而上、整体上全部重新开发，并且一次部署完成，而不是考虑将其划分为几个阶段来进行。实际上在绝大多数情况下，每次只在系统中寻找一个切入点，替换掉出现问题的部分，这样做总是可行的。（译者注：此处表明的意思是，像Derek那样希望一步到位的做法，成功的几率很低。）到最后，这也会是Rails专家将会告诉你的：一次只替换一个模块，每次都使用不同的代码库。以REST-ful服务的方式置入新的部分。不要让所有的系统代码都构建在单一的数据库架构（database schema）之上。

很多人都已经表达过类似的看法。David Heinemeier Hansson点明Chad Fowler的系列文章“The Big Rewrite”中也说明了重新开发项目的细节问题。

在这次争论中，宣传周期（hype cycle）的问题也被大家提了出来。宣传周期描述的是产品或技术在市场中引起轰动的过程。Rails的迅速兴起表明，宣传是它如此快就获得现在这样的普及和知名度的一个重要因素。其他许多技术也经历了类似的途径，比如Java、XML以及AJAX技术。

在宣传周期中，某项技术在引起人们热切期待之后，随之而来的就是“幻觉破灭期（Trough of Disillusionment）”。此时对技术的实际应用，会发现一些问题，并抹去这门技术上的神秘面纱。它也会跟在“期望膨胀期（Peak of Inflated Expectations）”之后出现，在“期望膨胀期”中，一些使用者可能会将这门技术视为银弹，能够解决所有的问题。抱有过高的期望也许能够解释为什么一个仅使用PHP的工作室会考虑用Rails重新开发他们的软件。

虽然有些人认为这样的文章对Ruby会产生不良影响，历史却告诉我们其他的技术也经历过类似的发展阶段。Java即是一例。在上世纪90年代后期，一些诸如Corel Office for Java这样的大型公开项目的失败，或是Netscape的Javagator项目（Netscape Navigator的Java重写版本）的终止，使得Java技术也走过了这样的发展时期。

有人将此次争论视为Ruby的反弹，虽然这看起来有些迟。今年早些时候，一个规模更大的、更加公开的基于Ruby的项目，似乎将以失败而告终。Twitter，一个搭建于Ruby之上信息发布系统，曾遇到严重的性能问题。有评论指出可能是Ruby解释器的性能导致了问题的发生，这也掀起了波澜，并引起对Ruby的关注。

现在，6个月之后，事情看起来有些不一样了。譬如：Twitter仍然处于在线运营当中，并且已经解决了性能问题，目前仍以Ruby实现。问题的解决方案记录在案，并且所有的人都能通过网络访问，比如与“提升Twitter的可伸缩性”或“浅析如何扩大规模”这两个谈话相关的在线演示。总体上看，问题实际上是由于架构方面的不完善引起的。

看英文原文：Ruby and the hype cycle

---

译者简介：郑柯，目前任职《程序员》杂志社高级编辑，有志于在中国的软件开发业界推广Agile的理念和方法论，笃信以人为本，关注Ruby，关注敏捷，关注人。参与InfoQ中文站内容建设，请邮件至china-editorial@infoq.com。

• 更早的 >