几个加速Ruby on Rails的编程技巧

Ruby 语言常以其灵活性为人所称道。正如 Dick Sites 所言，您可以 “为了编程而编程”。Ruby on Rails 扩展了核心 Ruby 语言，但正是 Ruby 本身使得这种扩展成为了可能。Ruby on Rails 使用了该语言的灵活性，这样一来，无需太多样板或额外的代码就可以轻松编写高度结构化的程序：无需额外工作，就可以获得大量标准的行为。虽然这种轻松自由的行为并不总是完美的，但毕竟您可以无需太多工作就可以获得很多好的架构。

例如，Ruby on Rails 基于模型-视图-控制器（Model-View-Controller，MVC）模式，这意味着大多数 Rails 应用程序都可以清晰地分成三个部分。模型部分包含了管理应用程序数据所需的行为。通常，在一个 Ruby on Rails 应用程序中，模型和数据库表之间的关系是 1:1；Ruby on Rails 默认使用的对象关系映射（ORM）ActiveRecord 负责管理模型与数据库的交互，这意味着 Ruby on Rails 程序通常都具有（如果有的话）很少量的 SQL 代码。第二个部分是视图，它包含创建发送至用户的输出所需要的代码；它通常由 HTML、JavaScript 等组成。最后的一个部分是控制器，它将来自用户的输入转变为正确的模型，然后使用适当的视图呈现响应。

Rails 的倡导者通常都乐于将其易用性方面的提高归功于 MVC 范型 — 以及 Ruby 和 Rails 二者的其他一些特性，并称很少有程序员能够在较短的时间内创建更多的功能。当然，这意味着投入到软件开发的成本将能够产生更多的商业价值，因此 Ruby on Rails 开发愈发流行。

不过，最初的开发成本并不是事情的全部，还有其他的后续成本需要考虑，比如应用程序运行的维护成本和硬件成本。Ruby on Rails 开发人员通常会使用测试和其他的敏捷开发技术来降低维护成本，但是这样一来，很容易忽视具有大量数据的 Rails 应用程序的有效运行。虽然 Rails 能够简化对数据库的访问，但它并不总是能够如此有效。
Rails 应用程序为何运行缓慢？

Rails 应用程序之所以运行缓慢，其中有几个很基本的原因。第一个原因很简单：Rails 总是会做一些假设为您加速开发。通常，这种假设是正确而有帮助的。不过，它们并不总能有益于性能，并且还会导致资源使用的效率低下 — 尤其是数据库资源。

例如，使用等同于 SELECT * 的一个 SQL 语句，ActiveRecord 会默认选择查询上的所有字段。在具有为数众多的列的情况下 — 尤其是当有些字段是巨大的 VARCHAR 或 BLOB 字段时 — 就内存使用和性能而言这种行为很有问题。

另一个显著的挑战是 N+1 问题，本文将对此进行详细的探讨。这会导致很多小查询的执行，而不是一个单一的大查询。例如，ActiveRecord 无从知道一组父记录中的哪一个会请求一个子记录，所以它会为每个父记录生成一个子记录查询。由于每查询的负荷，这种行为将导致明显的性能问题。