Refactoring, Rewriting and Lead Climbing

jskulski profile image Jon Skulski Updated on ・1 min read

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.
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.

Posted on Oct 2 '14 by:

jskulski profile

Jon Skulski


Long time Software Engineer. I like to build systems and teams to find pragmatic engineering solutions for socially responsible businesses.


markdown guide