Think of refactoring as the equivalent of washing your hands after using the restroom. It’s just something you always do as a matter of common decency.
The above quote is from Clean Coder by Robert ‘Uncle Bob’ Martin, about 12 % into the book. Yes, I’m reading it on my Kindle e-book reader. So, how would I react to a quote like that, in a post on this blog? Well, to be honest, when I read it, I just went, ah, ok, yes that’s it in my mind. Maybe I’ve blessed with a seven-years-old’s sense of humor. But more likely it drove something home in my idea of refactoring.
Ever since I read the first book written by Uncle Bob, and quite a few other authors on the subject, I’ve had a mantra going on and on in my mind on meetings and discussions with colleagues and fellow programmers on how to get a team to raise quality of their output. Often I’ve stated Refactoring is part of the concept of done, meaning that a task is not done unless you’ve looked over and cleaned up the code.
But, I never went further than that. Perhaps because of the total lack of interest in the room. Or terror. Or exhaustion. All the programmers go well, that’s a lot of useless work since I always write my code perfectly at once, in their minds all, the testers go What’s all that to us? and all the managers go That’ll never fit into budget.
Uncle Bob’s quote, a bit equivoque perhaps, cleared things up. Refactoring is not something huge and costly, something that you need to do as a last resort, when everything else has gone to shit; refactoring is done all the time. Now, the quote was made in a section on TDD, and as you may know, in Uncle Bob’s world, test driven development is pretty much mandatory. So you write tests, write code, test is green and then you refactor. Repeat. I was a little farther out in the loop, thinking that refactoring is done just before you push for a merge request.
Well, I think both can be true. If you have a complete set of tests covering 100 % of your code, refactor at your leisure. If not, perhaps a bit more caution is called for. But I do agree – strongly – that the dark magic idea of refactoring should be cleaned out and the concept should be brought in to every day work of a development team.
Refactoring should be in the planned estimate; indeed refactoring should be thought of as part of the work of a programmer. And perhaps, to drive that point home, to clean up the concept of refactoring a little bit, perhaps it is a good idea to add the Refactoring part into the concept of done.