Just attended the keynote at RailsConf Europe to hear David Heinemeier Hansson talking about Legacy code – code that you or someone else wrote a while back that isn’t, well, isn’t quite up to the standards you’d now expect to see – and how to avoid frustration working with legacy code.
It doesn’t sound like a particular exciting topic, and in truth, it’s not, but one excellent point to come out of it is the benefit of refactoring and improving old crufty code, rather than succumbing to the temptation to re-write it from scratch.
From a learning point-of-view, this was really interesting. I’ve often looked at a few of the earlier Django apps that I created a few years ago now and thought how I’d like to re-write them to apply all the things I’ve learned in the past few years, not thinking about the fact that it’s not only more sustainable, but also more beneficial to refactor the code bit-by-bit instead. I think it simply comes down to the fact that refactoring encourages continuous learning and improvement, rather than the dubious idea of “I’ll get it perfect next time round” (which will never happen). Of course, there are other factors too, for example, refactoring causes you to constantly think about loose coupling of your code, better encapsulation and stresses the importance of thorough test coverage, etc.
And I think it’s a principle that translates into other spheres of learning too – how often do you hear people expressing something like “I’ll get it right next time round” with respect to new relationships or company ventures rather than working to improve the current situation (where possible).
Speaking of Rails: I’ve been having a great time using the Rails framework over the past six months while developing with the Twinity.com team, but having come from a Python/Django development background there are definitely some things that I miss when I switch between the two (on both sides). I’m hoping to find the time soon to post some “Django & Rails: Can Django/Rails do X” posts.