I am now well over a week into putting BiQ on Rails, and I’ve been having so much fun. The fact that I actually getting paid for writing code that’s pretty and well tested means so much to the enjoyment of my work.
One of the more important decisions I had to make was wether I wanted to change my schema to fit the conventions of Rails. I weighted pros and cons, and ultimately I decided to not treat my schema as an untouchable ivory tower. I am confident that the benefits of doing so will far outweight the hassles of not doing so.
I am currently going through our entire model structure, taking a table at a time and renaming fields in it. At the same time I create a view that resembles the table I’ve just renamed. This is my backwards compatibility guarantee, making sure that all existing scripts should continue to work, but they’ll be querying views instead of tables - at least that’s the theory. If it turns out some scripts break, I figure they can be fixed by pretty much doing search and replace on the specific field names.
I take care to make sure that every migration is non-destructive, since I need to be able to roll back and have a database that structurally looks exactly like it did when I started.
After adding a new migration I run all migrations from version 0 followed by my test suite to make sure everything still works. Did I mention that migrations are frigging sweet?
During my initial rewrites I took an approach that I didn’t want to continue. I basically translated VBScript code to Ruby code line for line, which led to ASP on Rails or something. It definitely didn’t have the niceness of proper Rails or Ruby code.
For the rewrite proper, I’ve taken a more behaviour driven approach. Until now I’ve been going through the existing lowerlevel libraries, which roughly resembles the Rails models. For each function in the VBScript library I’ve written unit tests, that test the behaviour I read from the VBScript code. When the tests are written, I start writing the Ruby code that satisfies those tests.
This decoupling is important as it allows me to mentally break free from the structure and decisions I made when building the VBScript application, and allows me to take advantage of Rails proper (especially callbacks have proven extremely useful).
It also has the nice side benefit, that I end up with a comprehensive test suite, which is definitely not a bad thing.
So far this is how the stats look:
+----------------------+-------+-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Helpers | 246 | 156 | 3 | 24 | 8 | 4 |
| Controllers | 185 | 147 | 6 | 15 | 2 | 7 |
| Components | 0 | 0 | 0 | 0 | 0 | 0 |
| Functional tests | 88 | 63 | 2 | 10 | 5 | 4 |
| Models | 482 | 345 | 11 | 38 | 3 | 7 |
| Unit tests | 787 | 630 | 10 | 88 | 8 | 5 |
| Libraries | 102 | 65 | 1 | 6 | 6 | 8 |
| Integration tests | 0 | 0 | 0 | 0 | 0 | 0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total | 1890 | 1406 | 33 | 181 | 5 | 5 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 713 Test LOC: 693 Code to Test Ratio: 1:1.0
I don’t have a figure ready how many lines of ASP/VBScript code I’ve converted, so you’ll have to wait for another post for those.
Timewise, I am not quite on track, unfortunately. Primarily because there’s a lot of plumbing occuring at the moment - like the database migrations mentioned above. This is stuff that needs to be done only once, and later on I will hopefully be able to reap the benefits of those in form of meeting my milestones.
I am cautiously optimistic that I’ll meet my first deadline (24 days to go), and very excited that I am actually outputting code that I can be proud of for a living.
I wander how much time you spend on keeping the statistics? Or possibly you have an automated tool for it?
The stats above are generated by the rake stats task that's included in the default Rakefile distributed with every Rails application.
Let mem just get the facts straight here: 24 days + the 14 days you since the decision. Thats 38 days for converting several thousand lines of ASP/VBScript.
In itself that's an impressive achievement. INCLUDING writing tests for everything. I wonder why it took your employer that long to take that decision. Using only 38 days (potentially wasting the time). The worst thing that could happen is to throw everything away if it were not working.
I'm sure you will be successful with this impressive conversion.