DHH 访谈：Rails 2.0 新特性

历经数月开发，Ruby on Rails 2.0 终于正式发布。InfoQ 有机会就 Rails 2.0 与 Ruby on Rails 之父和最有影响力的支持者——David Heinemeier Hansson 进行了交流。

David Heinemeier Hansson 作为 web 应用框架 Ruby on Rails 的创始人而声名鹊起。Ruby on Rails 是我们用来构建 37signals 所有应用的基础软件。David Heinemeier Hansson1979 年出生于丹麦哥本哈根。在 2005 年从哥本哈根商学院毕业后，他移居到了美国芝加哥市。他是 37signals 的合伙人之一，这家公司拥有 Basecamp、Highrise、Backpack、Writeboard 和 Ta-da List 等一系列 web 应用。由于在 Rails 方面的工作，David 在 2005 年被 Google 和 O’Reilly 合办的 OSCON 大会授予最佳 Hacker 大奖。而 2006 年他又凭借 Rails 1.0 获得了年度卓越 web 开发工具震撼大奖（译注：2006 年 Rails 1.0 获得了 Jolt 大奖中 WEB DEVELOPMENT TOOLS 类的 Jolt Winner）。

Rob Bazinet (RB)：Rails 2.0.1 已经发布，你如何评价 Rails 团队的成果？

David Heinemeier Hansson (DHH)：大家的聪明才智能够汇聚在一起，这让我感到非常骄傲。来自全世界各地的人们能够在一起为发布一个被广泛使用的框架而工作，这听起来好像很不切实际。然而，我们确实做到了。像 Ruby on Rails 这样的大型开源项目为我们勾勒出了这样一个美妙图景：程序员们超越时间、国家和语言的障碍，通过远程协同的方式一起工作。

最后的成果同样令人印象深刻。Rails 2.0 经过了精心的设计，其妙处很难用言语表达清楚（众多细微的修改到底意味着什么呢？），但开发者在使用过程中会明显的感觉到。

RB：如果请你回到 Rails 发展的初始时间点上，重新审视你和 Rails 社区一路走来的历程，你能够想象会取得今天的成就吗？我的意思是，今天 Rails 所拥有的开发者、产品、培训课程、书籍、会议和其他社区支持。

DHH：其实还好。那时候我想，如果我喜欢用 Ruby on Rails，其他人也很可能会的。我的编程品味和美学并不怪异，很多人都和我拥有一些共同的赏鉴观。不过，自 Rails 发展伊始，我们确实已经在非常短的时间内取得了激动人心的巨大进步。

也许我那时候有一点悲观，我并没有料想到这样一个由奉献业余时间的志愿者们所开发的开源项目会产生如此大的影响。当然，看到当初估计的种种困难最终被克服，确实令我欢欣鼓舞。

RB：你认为 Rails 世界在未来几年中会如何发展？也许让你做出预测可能比较难，我只是想知道你对于未来发展的期望是怎样的？

DHH：我希望我们继续通力合作，不断解决 Rails 本身存在的各种问题。我们会继续坚持我们的愿景和理念，吸引更多的人们进入 Rails 世界。当然，并不是每个人都得用 Rails。Rails 是一个技术框架，但它同时也体现着风格和偏好。试想如果每个人都喜欢同样的餐厅或穿着出自同一位设计师之手的衣着，这个世界将会变得多么乏味？我们需要选择和差异来保持生活的趣味性。

所以如果我们能沿着现在的轨道继续前行，我就心满意足了。

RB: Rails 2.0 所做的更新相当多，考虑到这些之中可能存在的破坏性变更，你认为从之前版本向 Rails 2.0 的过渡会很容易吗？一些编程约定的变化也在需要考虑的范围内，包括将一些功能从框架的一部分移入到 gem 中。

DHH：我们已经花费了很长时间来保证从 Rails1.2.x 到 2.0 版本的迁移不会过于痛苦。在 Rails 1.2.6 中，我们已经加入了许多警告信息，使得编程者能循着一种可控的方式逐渐为 2.0 版本做好准备。如果你的应用可以很好的在 Rails 1.2.6 上运行，那么到 2.0 的过渡就是水到渠成之事。而那些被从框架内核移到插件的功能也可以通过几句简单的命令重新加入到应用中。

RB: 可否为我们概述一下本次发布的 2.0 版本相对于 1.2.6 有什么变化？其中的哪些重大变化使得 Rails 团队将版本编号做出了如此大的升级？

DHH: 主干版本通常意味着向后兼容性不再被保证。这也是为什么我们在版本上会有此一跃。我们之前一直在整理各种应该被清理的特性，而迈向 2.0 版本正是顺理成章之举。

RB: 我听说 Rails 的代码库规模已经从上一版本的 5 万 4 千行增加到了现在的近 9 万 4 千行。你怎么看这样一个变化？对于保持一个框架的简单性来说，这是一个需要注意的问题吗？也许这不是一个相关的问题，不过我个人确实觉得这一组前后对比的数字很有意思，不知道你是否也有此感觉？

DHH: 我想说随着代码行数的增加，Rails 在很多方面其实变得更加简单。许多关注点被抽象成了这样一种方式：如果你不想另辟蹊径，那么你就不需要担心它们。这也是合情合理的做法。对于我来说，代码行数本身并不说明什么问题，而使用者用这些代码所能够表达出什么样的内容才是意义重大的事情。因此如果框架的用户能通过 10 行而不是 100 行代码完成一个功能描述，这才是这个框架简单性的真正体现。这也使很多人们觉得 Ruby 比起像 Java 或 C#这样的语言更加吸引人的一个原因。

RB: 请告诉我你眼中 Rails 2.0 最重要的特性和那些最可能让开发者笑逐颜开的特性?

DHH: 我认为我们对于 RESTful 应用开发的侧重是 Rails 2.0 的第一主题。它包含了一组相关特性，从如何能在 routing.rb 中影射资源到我们为 respond_to 提供的多视图支持，再到 HTTP 基本认证等等。用 RESTful 的方式开发 web 应用确实是一个让人欢欣鼓舞的转变。虽然理解这一转变可能会花些时间，但一旦你经过这一阶段，你就会适应并享受它。

我知道 Rails 被用来开发像 Twitter 这样拥有大量用户的应用，不过…

RB: 新引入的特性和更新中是否有面向企业级应用可伸缩性问题的解决方案？

DHH: 我们所确定的任何简化开发的特性都会为大型应用带来更显著的好处。如果你你将一个应用所需的代码量减少 20%，那么对于一千行代码规模的项目可以减少 200 行，而 2 万行代码规模的项目则可以减少 4000 行。

当应用的处理负载增加时，应用本身没有什么变化。因为对于应用本身来说，没有什么需要变化。一直以来，人们通常增加线性量级的硬件来保证应用能够处理更多的用户请求（这也使应用可伸缩性的定义）。当然，我们已经对 Rails 的性能进行了显著的改进，所以每一个服务器将可以处理更大的负载（代码中加入了大量的缓存优化）。

同时，我们还改进了 HTTP 的使用，因此对于客户端来说，所感觉到 Rails 应用性能也会更加好。（主要是采用了 asset caching）。

RB: 你认为 Rails 从 Rubinius 或 Ruby 1.9 这样的项目中获得了怎样的益处?

DHH：所有人都希望速度能够更快。对于我来说，速度并不是一个 Rails 需要解决的需求，不过 Ruby 速度的提高的确是一个令人愉快的礼物吧。

RB：微软已经在 IronRuby 方面做了许多工作，不久之后我们可能就会看到.NET 上的 Rails。与之相对应的是 JRuby 和在 Java 虚拟机上运行的 Rails。对我来说这听起来这些是将 Rails 应用到那些将.NET 和 Java 作为标准的企业中。这些是否意味着 Ruby 和 Rails 的胜利？你如何看待这一趋势？

DHH：随着人们更多的接触像 Rails 这样的现代开发框架，他们在使用主流开发环境时遭受糟粕之害的可能性会越来越小。希望这样可以使得大家都能获益。所以我认为将 Ruby on Rails 吸收到现有的企业基础设施中是件好事。

RB：David，谢谢你今天抽出时间为我们介绍 Ruby on Rails 的最新发布版。

查看英文原文： Talking Rails 2.0 with David Heinemeier Hansson