Series
Refactorings
Fowler's catalogue, curated down to the entries big enough to carry a post. Patterns says what to build; this says how to get there from the code that is already running. Each post takes one refactoring: the mechanism, where the cost goes, the shape of problem it fits, when it is the wrong move and what to do instead, and the Go to write it, with the before and after and the mechanical steps in between drawn out, because a refactoring is a sequence of safe states and a picture of the endpoint hides the part that matters. Part of Under the Hood.
What Refactoring Actually Is
Refactoring is a change to a program's structure that leaves its observable behaviour identical, and a test suite is what makes the second half checkable rather than a hope. This post works one pricing function through six steps, from a single 34-line function to four small ones, with all 14,250 inputs in its domain agreeing at every state along the way. Then it slips one extra edit into step four, and 3,120 of those inputs disagree, which is the two-hat rule arriving as a number. It also measures what the rearrangement cost at run time: 5.8 nanoseconds a call before, 21.2 after, with a factor of two of that coming from one step.
Coming soon