I've spent a lot of time over the past few years working with Rails projects that were written by other people. Sometimes I've come on as a subcontractor to an existing codebase, sometimes I've taken over when another developer got bored or fired, sometimes I've been asked to do a code review.

Over the course of these engagements I've come up with a strategy for getting up and running on a new-to-me Rails codebase quickly. There aren't any hard and fast rules; there are still a lot of variable factors. But overall, I find these guidelines useful:

Start in environment.rb and figure out which version of Rails the project needs. In my case, I'm working with everything from 1.1.6 to 2.3.2.1 at the moment, so using gem Rails is pretty much a non-starter. If a project doesn't have vendored Rails when I get it, it will as soon as I figure out what version it wants to see. If you do vendor Rails into a shared project where others are working with gems, don't forget to .gitignore vendor/rails.

Next I look at bringing the database up from scratch. If at all possible, I ask for a copy of a current production database to avoid doing this. If I can't get one, I'll start by running migrations, just to see whether the migrations have been maintained. If migrating from scratch blows up, there's always schema.rb.

Next comes searching the code for require to see if I can figure out what gems the project needs (in rare cases, there are gems specified via the gem.config route, but so far I'm not seeing much of that). I install and upgrade any gems I can see as required, and then try to actually run the project via script/server. Usually this fails a few times as I discover missing dependencies, but I like to give it a few tries so I can have the code up and running while I explore it.

I spend a few minutes exploring vendor/plugins to see what non-gem plugins the project depends on as well. If it's using any that I'm not familiar with, I check out the readme - assuming there is one.

With the app running, I turn to the MVC heart of things. Here, the models are my first stop. If there are a reasonable number of models (say, anything under about 30) I just start at the top and look at each one, making particular note of association declarations. I haven't found an automatic ERD tool for Rails that I like, so I use this information to sketch out an ERD by hand, sorting out how the major entities connect to each other.

Next for me is routes.rb. Looking at this file is usually a good way to judge the sophistication of the previous developers. It also gives me some URLs to try out on the running code to see what happens. After I understand the basic routing, I'll spend some time in controller code, looking to see if it seems unduly fat or otherwise confusing.

Finally I'll spot check some views and helpers to see how clean the code looks. Usually I don't try to read all the views, though, unless the first couple I touch on show me systemic problems.

By the time this process is done, I usually have a rough handle on how the code is structured. Combine that with some exploratory use of the running application on my local box, and Rails' conventions, and I can go in and find the code that needs to be improved, evaluated, or fixed.