I love refactoring. Love it. When I’m TDD’ing, then as long as my tests pass, I can focus solely on refactoring my code: tweaking and improving my code to make it awesome. And I absolutely love this part. It appeals to my enjoyment of tinkering and my desire for efficiency.
You know that mirror in the first Harry Potter book — the Mirror of Erised? The mirror shows a person the deepest desire of their heart, and some have spent endless years of their lives staring at the mirror rather than living. Professor Dumbledore says it best:
Men have wasted away before it, entranced by what they have seen, or been driven mad, not knowing if what it shows is real or even possible.
And that, my friends, is exactly what refactoring does to me. Refactoring, as wonderful as it is, can become a distraction for me: a distraction that I willingly choose because it feels like a productive activity.
I often choose to spend my time improving code that is good enough over starting fresh on the next problem to be tackled.
My typical project workflow looks like this:
- Choose a feature to work on.
- Write tests for the feature.
- Implement the feature in order to get my tests passing, knowing that this first pass at a solution is decent, though perhaps not awesome.
- Refactor my code and optimize, making sure that my tests continue to pass. Make my code awesome.
- Ship. Sometimes, that means integrating into the master branch and deploying the code. Sometimes, it means telling my client that the feature is ready for a demo.
When my code doesn’t ship on time, you might think it’s because I get stuck at Step 3. Surely, the difficulty must have been in finding a working solution. But more often that not, the reason my code ships late is because I spent way too much time at Step 4 — so much time, in fact, that this feature doesn’t get demo’ed and the next feature doesn’t get started.
How should we think about refactoring so that we’ll know when that which began as productive has crossed over to become distractive?
What we need is to make sure that we’re clear on the purpose of refactoring, and then we’ll visit a few questions that we ought to ask ourselves so that we can decide if we should keep refactoring or if we should move on.
Photo by Kaleidico on Unsplash
Remind me again — what’s the purpose of refactoring?
By the way, if you aren’t in love with refactoring (yet), I’d recommend “Refactoring” by Martin Fowler, with Kent Beck. It’s an excellent primer filled with examples, and I go back to it time and time again as a reference and a reminder.
As we refresh our memories on why we refactor our code, let’s reference Fowler’s book for the purposes he outlines. The following are taken verbatim from Chapter 2 of his book:
- Refactoring improves the design of software.
- Refactoring makes software easier to understand.
- Refactoring helps me find bugs.
- Refactoring helps me program faster.
Excellent. Now that the purpose of refactoring is fresh in our minds, we need to learn how to set boundaries in our refactoring, so that we can find the balance between improving existing code and venturing out to write new code. To do this, let’s think about what kinds of refactoring we ought to do, followed by how to evaluate when we should stop.
#coding #productivity #software-development #programmer #tips-and-tricks
