Ruby on Rails项目的救赎

Ruby on Rails发布已有五年，在此期间，开发者编写了大量的应用。其中很多应用程序都是开发者们在学习Ruby和Rails的过程中写就的，代码质量堪虞，却已经运行于生产环境之中。

\

这些Web应用程序的规模数年来不断猛增，由于代码行数不断增加，它们已经变得臃肿，难以维护。这是很多开发者们不得不面对的情况。而且，他们几乎不知道从何下手。

\

一本新近出版的书能够帮助开发者解决这类问题，这本书叫做Rails拯救手册，由Mike Gunderloy编写。这本书也同时以PDF的形式发布，购买的用户可以终身收到最新版。InfoQ获得了一个和Mike直接对话的机会，试图了解到这本书的核心思想。

\

Mike介绍他的新书时说：

\

\

Rails拯救手册是我心血的结晶，当你面对一个乱糟糟的Rails应用程序，并且希望把它进行重构（或是仅仅使它能够工作），它能够一步一步指导你如何 去做。这本书介绍了一些简单Rails应用程序的共同问题点，并且在战略和战术级别上对如何重构，以及回到高效开发上给出了建议。

\

\

这本书面向的读者不是Ruby on Rails的新手。Mike解释了本书的读者群：

\

\

本书面向的是正在和陈旧的Rails应用程序搏斗，并且需要帮助的开发者。在大部分情况下；一个项目会有第二个开发 者，他会在第一个开发者不能发布可运行代码的时候被加入到这个项目中。有些时候，甚至不会有第二个开发者：一旦你意识到你可能会有问题（或者，很多问 题），没有人能够阻止你重构你的项目。

\

\

修正代码问题的关键一环便是知道问题在哪，有些非常明显，但是有些就不是。关于这个问题：

\

\

表面上说，Rails项目中发现问题的数量和客户需求无关。我看到过这些问题是以两种形式。开发者不能够按时发布能 够工作的代码，或者发布的新特性破坏了程序的其他部分。当然，后者是最常见的问题之一：缺乏足够的高质量测试覆盖。当你获得源代码的时候，经常可以在这些 地方发现问题：由于缺乏对数据库层的考虑，不可思议的臃肿的控制器以及充满了SQL语句的视图等等导致了低下的性能。

\

\

一旦这些问题被找出，那么需要一个结构化的方法来修正它们。Mike给出了一个开放的结构化的方法：

\

\

首先，你需要了解客户的需求，明白哪些修改是必须的。客户需要了解到当开发者试图使程序稳定的时期内，应用程序可能会很少甚至没有新特性。这个过程的一个 关键点在于设置良好的沟通渠道，及时通知客户——经常你需要处理一些不可思议的遗留问题，但是不会满足客户的需求。透明是这个过程中的口号。

\

在你确认你已经获得了能够继续进行的足够多的支持之后，下一步就是对现存代码做一些巨大的改动（假设这些都不是你写的）。检查Rails的版本，将一份拷 贝放到你的桌面（如果可以的话），检查一下路由器以及模型、控制器和视图。仔细查找问题点。通常客户将会知道性能和功能问题出在哪儿；仔细听他们说。

\

当你已经知道代码中的问题之后，那么着手重构它们。通常重构之后需要进行测试。你需要确认问题已经走上正轨，而且开发过程处于掌控之中。

\

\

我们然后讨论了通过选择一些容易完成的目标来达到快速制胜：

\

\

书中有一些秘诀，能够轻松为客户带来益处（也能够帮助他们成为反馈式的开发者）。例如，花费在理解数据模型和寻找模式的时间能够帮助你寻找到如何得到本质的性能提升。

\

\

也有一些地方需要注意，他介绍了一些入手点：

\

\

此外如果需要关注数据库层（尤其是在开发者的第一个或者第二个Rails项目），通过运行Google Page Speed类似的工具能够知道那些地方存在性能瓶颈（性能问题是客户最关心的问题之一）。在一个公共站点，确保有一些异常通知来告诉你哪些东西失败了，是 另外一个能够知道代码的哪些部分需要特别关注的方法。

\

\

当被问道他在Ruby社区的背景以及他如何意识到这些常见问题的类型的时候，Mike指出他多年的咨询经验以及学习帮助了他：

\

\

在过去两年中，我已经帮助了大量的项目转到正轨来，但是为了客户的信心，我不能透露他们的名字。我也曾经在做Action Rails的 时候，做过一些代码检查。这些项目有些只是一些简单站点，基于10个左右模型，但是这些模型缺少了一些基本的Rails功能，例如模型关联（因此编写了太 多自定义代码），有些却是大型应用程序，已经被部署用作主要的功能实现，但是却被Bug缠身。我花费了很多时间在客户的项目以及转包合同，而不是在产品或 者临时工作中，这些并没有给我太多机会来审视它们为什么失败。

\

\

更多信息可以在Rails拯救手册的官方站点上找到。

\

Mike Gunderloy在多种语言和平台上有着二十年的开发经验。从2006年开始，他全职转向Rails工作，对于和各种规模的分布式敏捷团队的协作，以及 和各类项目参与人员（从开发者到项目经理）的合作有着丰富的经验。他对core Rails也是贡献良多，还是Rails文档团队的成员。此外，在他在Lark集团的本职咨询工作中，是一位在高端Rails咨询领域的合伙人，同时也是RailsBridge的创始人之一。

\

查看英文原文：Rescuing Your Ruby on Rails Projects