I look after an Rails app, that's about to have some key user facing parts renamed (like urls, and other such change like renaming 'blogs' to 'journals' and so on)
I'm slightly worried that over time, having loads of older names in the codebase for all the methods, routes and classnames is going to be difficult to read and maintain.
What's the best way to deal with changes like this?
And where are the gotchas like to be when aliasing methods and classnames, or running migrations here?
Thanks
I would rename the internal classes to match the external names, otherwise it just causes confusion when talking about the code. Sure, routing can make the external changes easy to switch, but there's nothing like reading in the code what you see on the webpage.
After the rename, I'd load the app up in a staging environment with the live data to test the migration, and then run something like tarantula ( http://github.com/relevance/tarantula ) to crawl your app looking for obvious broken issues that you & your tests may have missed.
If the app is development and hasn't yet gone into production you're safe to just go back and rename the migrations/models/views etc... and do a rake db:migrate:reset and be done with it. You should have enough tests to ensure that the rename didn't break anything, and if it does you should increase your test coverage in that area.
In so far as doing this for an app that is currently in production I suggest doing it incrementally so that the surface area for the change is reduced:
Change your routes
This is probably the biggest change. Updating your routes first will give you a chance to fix all of your views.
Update your models/controllers
You can do this without changing the database. You can make your model point to a new database table by using set_table_name "OldTable". This means you can make any database changes out of band of the release.
Change the database
Hopefully you're using a migration, in which case just do a table rename and remove the set_table_name.