Ruby on Railsが世に出て５年ほどになる。この間，開発者たちは数多くのアプリケーションを開発してきた。多くのアプリケーションがRubyないしRuny on Railsの習得と並行して開発されているため，ベストプラクティスが用いられているとは言いがたいものの，それなりのWebサイトとして運用にこぎつけている。
これらのアプリケーションが年月を経ることでコードの規模が大きくなり，携わっている開発者も世代交代するなどして，メンテナンスが難しくなってきている。これは数多くの開発者が経験するシナリオであり，どのようなアプローチが最善か，何から始めればよいのか分からないことも少なくない。
このような状況のプロジェクトに問題への対処方法を指導するものとして，Mike Gunderloy氏による Rails Rescue Handbookという本が新たにリリースされた。本書はPDF形式でリリースされ，購入者は無期限にアップデートを受けることができる。InfoQ は本書の背景にあるアイデアについてさらに詳しく知るために，氏から直接話を聞く機会を得た。
Rails Resuce Handbook はどのような本なのだろうか。
Rails Rescue Handbool は，混乱を来したRails アプリケーションに直面して，それをプロフェッショナルの水準にまで戻したい(あるいは何とか動作するようにしたい)と思ったときに行うべき手段のエッセンスです。本書では，標準以下のRailsアプリケーションに共通する問題点について概説した上で，その窮地を脱して開発生産性を取り戻すための戦略的，技術的レベルのアドバイスを提供します。
本書の想定する読者が Ruby on Rails の初学者でないことは明らかだろう。では本書が本当に役に立つのはどのような人なのか，氏は次のように説明する。
本書が対象としているのは，Railアプリケーションに苦労しながら取り組んでいて，まさに支援を必要としている開発者たちなのです。多くの場合，彼らは最初の開発者が失敗したコードを引き継いだ，プロジェクトの第２世代の開発者たちです。しかし場合によっては，オリジナルの開発者が本書を必要とすることもあるでしょう。どちらにせよ，ある問題(というよりも「山積する問題」でしょうか)の所在に気づいた開発者が，自身のプロジェクトを立て直そうとする努力を妨げるものはありません。
コードの問題を解決する第一歩は，問題の所在を確認することだ。これは明白なこともあれば，そうでない場合もある。問題点の特定，というテーマについては，
外面的に問題の発生を示す第１の兆候は，それがユーザの要求するものを提供できないRailsプロジェクトであることです。これは一般的に，２通りの形で現れると私は考えてます。開発者が妥当なタイムスケールでその機能を実現できない場合，あるいは新機能の実装がアプリケーションの他の機能を損なうような場合です。後者はもちろん，よくある問題のひとつである「テスト範囲の不足」が発生していることを示します。ソースコードにアクセスすれば他にも気づくことがあるでしょう。データベース層の考慮不足によるパフォーマンス不良，やたら肥大化したコントローラ，SQLでいっぱいのビュー，といった具合です。
問題点が特定されたならば，解決のための構造的アプローチが必要になる。ここで氏は，オープンな構造的手法を指示している。
開発者であるあなたは，まず最初に，対策作業に伴うものについてユーザの了解を得る必要があります。あなたが状況を安定させようとしている間，新たな機能が追加されない期間が発生するということを，ユーザに理解させなければなりません。このプロセスで重要な点のひとつは，ユーザが作業状況を把握できるような手段を講じておくことです。前任者のお粗末な仕事のおかげで，とんでもなく腹立たしいバックログを抱える羽目になることが往々にしてあります。ここでは透明性がモットーです。
作業を進めるための十分なサポートが得られたと確信したならば，次のステップは既存コードのしっかりとした解析作業です(あなた自身が書いたコードでなければ，ですが)。Railsのバージョンを確認し，アプリケーションのコピーを(可能ならば)デスクトップに取得して，ルーティング，モデル，コントローラ，ビューを調べます。問題点の抽出に取り掛かりましょう。パフォーマンスや機能的な問題については，ユーザがたいていよく知っているものです。彼らの話を聞きましょう。
コードのホットスポットを特定できたならば，そこに入って改良のためのリファクタリングを始めます。テストコードを新たに書かなければならない場合も多々あるでしょう。状況が改善していること，開発プロセスがコントロールされていることを確かめながら，確信を持って作業を行ってください。
続いて私たちは，簡単に成果を上げるためにまず“低い位置にある果物”を摘む，というプロジェクトアプローチの方法について議論した。
本書には，顧客に対して簡単に成果を上げる(そして役に立つ開発者としてのあなたの評価を確立する)ための秘訣がいくつか紹介されています。例えばデータモデルの理解とスキーマの確認に時間を費やせば，パフォーマンスを大きく向上するインデックスの追加場所を見つけられることがよくある，というようなものです。
比較的簡単な成果を獲得するためには，注意を払うべき点がいくつかある。氏はその出発点を提案する。
まずはデータベース層(これは初期のRailsプロジェクトでは特に無視されやすい部分です)に注意を払いましょう。それに加えて Google Page Speed などのツールを利用すれば，他にもパフォーマンスを手早く改善できるポイントが見つかると思います(一般的に言ってパフォーマンスは，ユーザが最も注意する部分のひとつですから)。すでに公開中のサイトであれば，"現地"で発生する問題の内容が確認できるように，適当な場所に例外通知などを入れます。これもまた，最も注意すべきコードの特定を容易にするために，簡単に実行できる最初のステップです。
氏のRailsコミュニティにおけるバックグラウンドと，この種の共通的問題の認識を獲得した方法について尋ねたところ，氏自身の長年にわたるコンサルティング経験に加えて，次のような活動について説明してくれた。
私は過去２年間にわたって，１ダースほどのプロジェクトの改善に成功してきました。ただし機密上の問題もありますので，名前を明かすことはできません。またAction Railsにおける活動の一環として，コードレビューなどの作業を行う機会にも恵まれました。これはモデル・アソシエーションのような基本的なRails機能さえ使用しない(そのためカスタムコードを書き過ぎていますが)，10個程度のモデルを基本とするシンプルなサイトから，非常に多くの機能を提供していて，それゆえにバグ報告の多さに悩まされている大規模アプリケーションにまで及んでいます。私はRailsに関与した時間の多くを，製品やプラグインに関する作業よりも，ユーザ向けプロジェクトやその下請作業に費やしてきました。その過程で，プロジェクトが失敗する様子を目の当たりにする数多くの機会を得ることができたのです。
Rails Rescue Handbookについてのさらに詳しい情報は，同書のWebサイトにある。
Mike Gunderloy 氏は，数多くの言語やプラットフォームに渡って20年の開発経歴を持っている。2006年からはフルタイムでRailsに取り組んでおり，分散開発やアジャイル(agile)開発チームにおいて，プロジェクト管理から開発に至るすべてのレベルでの幅広い作業を経験している。また Railsコア開発にパッチ提供で貢献するとともに，Rails Documentation Team のメンバでもある。Lark Groupを通じてのコンサルティング活動に加えて，氏は最高レベルのRailsコンサルタントチームである Action Rails のパートナーであり，RailsBridgeの発起人のひとりでもある。