Ruby 与技术成熟度曲线模型

最近有一篇关于基于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 。