In case you missed it… It has come to my attention that Monday’s livestream went to the wrong stream on YouTube! This means if you followed the link I shared with you on Monday, you likely sat there waiting for 2 hours, only to be disappointed by a lack of live programming. 😞

Alas, the livestream did happen, just at a different link by accident. So here’s that link, so you can watch the replay, if you so desire.

“Small, frequent commits is a great idea, but it’s just not possible when refactoring.”

Agree? Disagree?

I disagree. Vehemently.

Do you know why?

Because I refactor all the time, as a series of small, frequent commits.

It makes it easier to reason about what I’m doing. It makes it easier for others to follow (whether via pair programming or code review). It makes it easier to test. It makes it easier to back out a change if I discover I made a mistake (that happened yesterday!)

In a nutshell, all the benefits of working in small batches on a new feature also apply to refactoring.

I’m right now nearing the end of an approximately 2-week refactoring process on a portion of one of my clients’ codebases. The goal is to improve error handling. The general pattern I wanted to implement was fairly straight forward: Change a callback from doThing() to doThing() error. But the function that accepts this callback is used in aproximately 100 places in our code. So that means in all, I need to touch 100 call sights.

But that would be a terribly large one-shot change. So instead I duplicated the function that accepts the callback, and made the copy accept the new type of callback. Then I can update the callers one by one, possibly doing other related cleanups at the same time. And I can validate each one as I go.

When the final call site is updated, I can delete the old version of the function.

(This is actually a highly simplified version of the entire refactoring I did, but this is email, not a 10-part docuseries, so we’ll leave it at that.)