Originally written in 2014, republishing for dev.to
I’ve thrown the word refactor around a lot. I’m like this:
“What are you working on for the next three weeks?”
“I am going to refactor the login system”
M. Fowler, in his wonderful book Refactoring, gives the definition of ‘a change made to the internal structure of software…without changing its observable behavior’
So technically, alright. Go ahead, me, refactor the login system for three weeks. But words and accuracy are important. Perhaps I should just say I’m rewriting the login system.
Fowler also gives this definition:
applying a series of refactorings without changing its observable structure.
I’m having more success with this definition. It’s safer and warmer and more comforting. If it’s a multiweek process without releasing to production, I’ll call that a rewrite. And rewrites are hard and scary and riskier. So I try to avoid ‘em.
Lead climbing. Many anchor points, several discrete releasable points.
When I conceive of a refactoring as a series of discrete steps to improve the quality of the code, I take those small steps. By discrete, I mean releasable to production.
Extract a method. Create a small class. Rename a variable. Add a type hint. Make a small, safe, confident commit in the right direction.
Small steps carry us a long way.
Top comments (0)