Starting Fresh, Without the Big Rewrite 2
If you’re working on a project with a couple years of code under it’s belt, you may have moments of desire to completely throw the whole thing out and start anew. But, if you’re working for someone else, you know that your boss or client probably won’t like that. After all, he’s paying you to finish feature A! But, you lament, feature A builds on top of feature B that already exists but is written in a terribly unidiomatic, pre-TDD, pre-REST way, way before you or someone else learned the dark arts of coding mastery. Legacy code, argh!
So what should you do? What are your options? A) Ignore the problem and build the new feature on top of the existing badly written code. Watch things get even worse. B) Try to quickly fix the badly written code in-place so you can get on with it. Trigger cascading test failures, and palm your face. C) Start over and rewrite the entire project, get fired for being 6 months late on your estimate. None of these sound any good!
I think I may have found a solution that works for me, especially with Rails.
Start a fresh Rails project. Boom! It’s fresh and clean. Now you have room to work. The beauty of Rails is how quick it is to get started. Choose the aspect of the project you want to work on. Got some legacy code thats bugging you? TDD/BDD it from scratch, the Right Way. The idiomatic, Rails Way. Once you get it to the point where it’s working correctly and passing all tests, you can merge the new code into the main project, replacing the older, ugly, what-were-they-thinking legacy code that was getting in the way.
Now you can work in a clean environment and just focus on the problem at hand. This allows you to make progress quickly, and get rid of the old crap without having to completely start from scratch.
- Posted in Ruby on Rails, Web Development
- Meta permalink, rss, atom
- Save It:
del.icio.us | 
Reddit.com
Interesting approach! How difficult was plugging the new code back into the larger project? Did you develop the new code with an eye towards how it might fit back into the rest of the system or did you delay those decisions to “merge time?”
I’d also be interested, both subjectively and objectively, in the difference in the code base pre and post rewrite? Did test code coverage go up? Average method size go down?
I’ve performed a similar task against my own code base (What? Legacy code? Me? nah…) but simply in a local Git branch that I’d keep “git rebase master”ed against the latest. That approach worked well for me as I’d do these rewrites in “spare time” while working on release features.
Gavin – I will let you know how the merge goes soon, but yes, I am developing the new code with an eye towards dropping it in to the larger project. Class names, db fields, etc have to match. Still using the same test framework – rspec. Much of this stuff had poorly written test/unit tests from another developer, and was done before certain new rails features make things easier – such as dirty attributes. Test coverage is going way way up.