BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Rescuing Your Ruby on Rails Projects

Rescuing Your Ruby on Rails Projects

Leia em Português

This item in japanese

Bookmarks

Ruby on Rails has been around for about 5 years and in those years developers have created a lot of applications.  Many of those applications were created while learning Ruby and Ruby on Rails and may not have used the best practices but yet made it into live web sites.

These web applications have grown over the years, they may have become hard to maintain with an increasing number of lines of code while the developers working on them may have also changed.  This is the scenario many developers are faced with and often don’t know the best approach to take or where to get started.

A new book has been released to help address problems in these types of projects called the Rails Rescue Handbook, by Mike Gunderloy.  The book is released as a PDF and buyers receive updates for life.  InfoQ had the opportunity to catch up with Mike to better understand the idea behind this book.

When asked to describe the Rails Rescue Handbook:

Rails Rescue Handbook is my distillation of the steps to take when you're faced with a Rails application that is a mess and want to bring it back to professional standards (or just make it work). The book provides an overview of some of the common pain points in sub-par Rails applications, and offers advice on both the strategic and tactical levels for getting out of the hole and back to productive development.

This book clearly has an intended audience who is not someone new to Ruby on Rails.  Mike explains who should find this book most useful:

The book is aimed squarely at developers who are struggling with Rails applications that need help. In many cases, this will be the second developer on a project, brought in after the first one has failed to deliver working code. Sometimes, though, it might even be the original developer: there's nothing to prevent you from rescuing your own project once you realize that you have a problem (or, more likely, many problems).

Part of fixing any problem in code is first knowing a problem exists, some obvious, but others not so much.  On the subject of indentifying problem areas:

Externally, the number one indication that something is in trouble is a Rails project that isn't delivering what the client needs. Typically, I'm seeing this manifest itself in two ways. Either the developer just can't get working features delivered in a reasonable time scale, or else delivering a new feature breaks some other area of the application. Of course, the latter is an indication of one of the most common problems: lack of any decent test coverage. When you get access to the source code, it's common to find some other smells: bad performance due to lack of consideration of the database layer, incredibly fat controllers, views full of SQL and so on. 

Once these problem areas are identified there needs to be a structured approach to fixing them.  Mike prescribes an open and structured method:

First, you need to come to an understanding with the client about what rescuing will entail. The client needs to understand that there's going to be a period of few to no features while you get things stabilized. One key part of the process is to set up ways to keep the client informed - often you're going to be dealing with an incredible backlog of frustration from previous work that didn't deliver what they needed. Transparency is the watchword here.

After you're sure you've got the support to proceed, the next step is to do some serious exploration of the existing code (assuming that you didn't write it yourself). Check out the version of Rails, bring up a copy of the application on your desktop (if you can), look at the routing and the models and the controllers and the views. Start mapping out the pain points. Usually, the client will know where the performance and functionality issues are; listen to them.

When you've identified hot spots in the code, go in and start refactoring to make them better. Often this will involve bringing in testing for the first time as well. You want to be very sure that you're actually making things better and getting the development process under control.

We then talked about approaching projects by picking the “low-hanging fruit” first to get easy wins:

There are some tips in the book that can produce an easy win for the customer (and help establish you as a responsive developer). For example, time spent understanding the data model and looking at the schema will often show you places where adding indexes can get you a substantial performance boost.

There are several areas to pay attention to for relatively easy wins, he suggests some starting points:

In addition to paying attention to the database layer (and oft-neglected area, particularly in people's first or second Rail projects), running a tool like Google Page Speed will often show you other places for a quick performance fix (and performance is one of those things that clients are usually very aware of). On a publicly available site, making sure you have some sort of exception notification in place to tell you what's failing "in the wild" is another easy first step that can point out the parts of the code that need your most urgent attention.

When asked about his background in the Rails community and how he gained the awareness of these types of common problems, Mike pointed to his many years of consulting experience and learning through doing: 

I've helped successfully turn around a dozen or so projects in the past two years, but I'm serious about client confidentiality so I can't mention names. I've also had the chance to do code reviews on others as part of the work I'm doing with Action Rails. These have ranged from simple sites based on 10 or so models that missed basic Rails functionality like model associations (and so wrote way too much custom code), up to major applications that had deployed substantial functionality but were plagued by bug reports. I've been spending much of my Rails time in client projects and subcontracts, rather than in product or plugin work, which has given me quite a few opportunities to see the ways in which projects can fail.

More information about the Rails Rescue Handbook can be found on book’s web site.

Mike Gunderloy has two decades of development experience spanning multiple languages and platforms. He's been working with Rails full-time since 2006, and has extensive experience in working with distributed, agile teams at all levels from project manager to developer. He's contributed patches to core Rails, and is a member of the Rails Documentation Team. In addition to his own consulting work through Lark Group, he's also a partner in the high-end Rails consultancy Action Rails and one of the founders of RailsBridge.

 

Rate this Article

Adoption
Style

BT