A great blog post by Szczepan Faber talked about 10 rules of unit testing. In this post, I want to discuss on the second rule in his post, which is: “It’s not only about test code but I need to say that anyway: Best improvements are those that remove code. Be budget-driven. Improve by removing. The only thing better than simple code is no code.”

To me, it means one fundamental thinking in coding in general, that is, “do the simplest thing that could possibly work”. I also refer this rule as Occam’s Razor.

This rule can apply to Rails migrations strategy as well. If your application is already in production, then you have no choice but using migrations. But if it’s still in development, I always avoid to add a migration script for any tiny change to my schema, instead, I would just change existing migration scripts.

So the rule for doing migration becomes: for each table, or tables associated by their function areas gets their own migration. To make changes, modify your scripts. For example, if I change column name from user_id to login_id, I will just change my script from

t.integer :user_id

to

t.integer :login_id

The downside of this approach is that each time you change it, you need to do a migrate:reset. But since it’s in development, who cares.

The gain is big, by doing this, my migrate directory always keeps small and clean. And this also solves a problem Obie Fernanandez mentioned in his great book “The Rails Way” which is, in a large team, developers can step into each other’s toes by having conflict sequence numbers, with huge number of migrations, that could be a nightmare. But if we just change scripts themselves, all we need to do is merging the same file, instead of renaming a lot of files.

You don’t have to find a mechanism to archive your migrations because you don’t need to archive.

As long as I can use this rule to achieve the same functionality that full migration approach offers, then it is a simpler way and, thus, better.