Large Rails apps have a way of gathering cruft. One popular cruft hideout is
config/routes.rb. It doesn’t change very often, and when it does change it’s usually a person getting in there, adding a new resource or a new action, and getting out. So from time to time it’s worth checking the routes file and tidying things up.
Probably the most obvious cleanup is removing unused routes. A route which has no corresponding action won’t produce a warning, so you have to ferret these out yourself. Take a look at the routes file and see if anything obvious jumps out at you; if you know that a bunch of admin code was just extracted into another app you can look around for routes in an
admin namespace. Do a
git whatchanged -p app/controllers/ config/routes.rb (or as Brian Ewins suggests,
git log -p --no-merges app/controllers/ config/routes.rb because whatchanged is deprecated) and see if recent controller or action removals included removal of orphaned routes. Grab the traceroute gem and see what it finds. This will lead to a smaller file, faster load time, and generally less confusion.
There are some minor cleanups that are worth a look. Sometimes I’ll see resources with empty blocks:
This is usually leftover from an earlier cleanup; just delete those empty blocks. Same goes for empty
member or `collection blocks. This is trivial, but it makes the file easier to read.
The default resource declaration – e.g.,
resources :products – results in routes to seven actions:
destroy. Occasionally you’ll see a resource declaration with all seven actions declared explicitly in an
only constraint; in that case you can remove the entire constraint. So this:
can be boiled down to:
The same applies to
resource declarations, of course, but with six actions instead of seven.
A variant on this is to replace
only blocks with
except blocks when those would be shorter. That is, you can replace this:
Some people prefer wrapping single actions in an array when declaring resource restrictions; that is, they prefer
resources :products, :only => [:create] to
resources :products, :only => :create. I tend to use the bare symbol, but I can see where those folks are coming from – makes it easier to add other actions – so whatever works for your team.
This one is not like the others in that it makes your routes file bigger. But it reduces overall complexity, so I think it belongs here anyway. If you have an action that is serving only to redirect requests to another URL, you can replace that action with a route. So you can replace:
1 2 3 4 5
With this route:
This trades five lines of code and a file for a single route, which seems like a win to me. There are times when this isn’t quite as clearcut, like when the redirect is to a more complicated route, but generally this is a just a more effective use of the Rails API. Shades of ‘refactor to the standard library’!
Another change which increases the routes file size but reduces the number of routes generated is to add
only blocks where appropriate. I’ve found that many resources don’t need a
destroy action since that’s handled in an admin app. So add
only blocks and reduce your
rake routes output.
There are other cleanups which could be made around shared constraints, unnecessary
controller specifications, and redundant
path_names usage. But I feel like usage of these features is rare enough that if you’re using them you’re probably reading the documentation.
When making changes like this, one option is to do a clean sweep and tidy up everything at once. I can see why people do this; it’s one code review, one deploy, etc. But I usually do these things piecemeal – one or two changes at a time. I do this because there’s lower risk; if I’m only changing a few things it’s easy to locate the culprit if something goes wrong. It also lets me do the work in small chunks; instead of devoting a full day to routes file cleanup I can do 10 minutes of work here and there whenever I have time. Also, small changes are more helpful for co-workers to see what’s going on. If someone sees a commit with a small and straightforward route cleanup, that person might be more likely to do a similar cleanup next time they see a similar issue. And if I’m headed down a wrong road with a cleanup strategy, someone can catch it earlier on in the process before I do too much damage.
This post is cross-posted from Tom Copeland’s blog.