Hacker News Reader

Comment by jacobkg | Hacker News Reader

One of my biggest lessons from the book is right in the introduction. To paraphrase: "If a change you want to make to the codebase is hard, refactor the codebase until that change is easy, then make the change".

I always try to either be refactoring or changing behavior but not both at the same time. That has kept me out of a lot of trouble.

View on HN

This quote is inspired by Kent Beck who coined it while he and Martin Fowler were working together.

> "For each desired change, make the change easy (warning: this may be hard), then make the easy change"[0]

[0] https://twitter.com/KentBeck/status/250733358307500032

Edit: Added a link to his first Tweet containing the quote that I know of.

A rule of thumb that I try to follow (but often neglect) is to keep changes either sweeping/shallow or narrow/deep. So if you're refactoring a module and that has implications across the codebase, don't try to make a deep change to the business logic at the same time.

Keep those tasks separate.

I find that I will be making a change, notice a refactoring, and then get lost in the rabbit hole. I try to keep a pad of paper by me at all times now, and if I notice something, then I will make note of it, but keep moving with what I was doing. Then after I'm done, I can revisit the notes that are on my paper. Right now, a lot of those become backlog techdebt items that will get fixed in the future.

The problem I deal with is that if I see something worth improving that doesn't get fixed now as I see it, unless it's a really significant issue, the code won't get improved down the line

At work, we often create tickets to deal with such things and have epics dedicated to "code gardening". These are often addressed on a Friday afternoon or at other times when one feels their productivity is especially low.

One approach I sometimes take is to make the refactoring in one commit and the change in another. They can go into the same PR (within reason), but they're clearly separated out.

This is the approach I try to take. It requires discipline but it has helped on several occasions.

The biggest benefit is that it makes code reviews easier for others because the reviewer can step through each commit. This makes the refactoring changes much more obvious.

Splitting the commits also makes it much easier to roll back a functional change that goes wrong or isn't needed while still keeping the refactoring improvements.

I typically start by adding some test cases or extract code (say as a function/method) add code to test it and keep repeating the cycle. I feel confident with this approach, especially with dynamiclly typed language like Python.

Reply on news.ycombinator.com