Code health

The smallest useful refactor

A refactor does not need a parade. Sometimes the best version is a tiny move that makes tomorrow obvious.

~5 minCoding
scroll
01 · the shape

Big cleanup is where scope goes to hide

The dangerous refactor starts with "while I am here" and ends with a pull request nobody can review. The safer move is to make the next change easy, then stop.

git · tiny diff

The useful signal is usually already there.

change looks calm

A tiny patch rarely touches only one thing. Push it and watch the review surface appear.

02 · the move

Refactor around the change

Extract the branch you need to touch, name the concept, add a test around current behavior, then make the actual feature change in a separate commit if possible.

billing.ts

A small name can remove a lot of local guessing.

03 · the check

Make review easy

A useful refactor should have boring tests and a boring diff. If the reviewer cannot tell behavior stayed the same, split the patch.

change confidence lab
guessy
safe0
fragile: this change still depends on hope and a lucky deploy

Flip the switches and watch the story turn into a tiny operating model.

0concept extracted at a time
0commits: preserve behavior, then change behavior
0drive-by rewrites needed
04 · the takeaway

Leave a cleaner path, not a new maze

Refactoring is maintenance with manners. It helps most when the shape of the change stays obvious.

source trail