A talk I really enjoyed at Rails Conf 2007 was Clean Code by Robert Martin. An important idea from that talk was “Always check in your code a little bit cleaner than when you checked it out”. I never looked at refactoring as being that simple, but it is. Prior to this talk, I looked at refactoring as this big undertaking. I mean the whole application can use some improvement, right? I also tended to take on big refactoring endeavors by deleting the current code and starting over. Robert Martin urges against this, since you might break the current application with the rework code, and that’s much worse than ugly code. At least the ugly code is working. Tackling the smaller refactors, by improving the code a little bit at a time, the refactoring process becomes manageable.
Refactoring
When I first started out developing, I was concern with getting things done and working as quickly as possible. I didn’t really understand the benefits of refactoring. Later on in my development career, I understood why refactoring was important, but I still couldn’t find any time to refactor – unless it was physically added to a project schedule, which wasn’t too often.
What I have finally come to understand, is that I just needed to find time to refactor. The time I spend on refactoring now, will probably save me a lot more time in the future tracking down bugs in a bloated code base. So today, when I ran into an issue because of a bloated code base I decided to refactor the code. Sure I spent all day cleaning up the code, but I feel more confident in the code base and I was able to add much more rpecs.
So, how often do you refactor? and when do you find time to refactor?
