Same behavior, new shape

Think of it when the code works but is hard to change, or one change mixes cleanup with new behavior.

In everyday life

A cook rearranges the kitchen so the pans hang by the stove. The meals should taste the same. If the cook also changes a recipe that day, nobody can tell whether a bad dish came from the move or the recipe.

One case

A developer tidies a bank app’s interest code: one 300-line functionA named piece of code that takes inputs, does one job and gives back a result, such as total(cart). becomes five short ones. In the same change, they move one rounding step from the end of the math to the middle. In some months, savers now earn 1 cent less. Nobody notices for half a year, because the change was labeled “cleanup”.

A “cleanup” moved a rounding step
The case, cell by cell1 cell = 1 month
Interest before the cleanup ($)
4.174.184.184.194.204.20
Interest after the cleanup ($)
4.174.174.184.184.204.19
Months paid 1 cent short
3
Behavior changes planned
0
The cleanup and the rounding change shipped together, so the review saw only the cleanup.

Every case

A refactor is safe only when you can show that behavior stayed the same. That takes tests that check what the code does, run before and after the change. Mix a cleanup with a real change and that proof is gone: a reviewer reading a large diffThe lines a change adds and removes, shown side by side. Reviewers read the diff to see what changed. cannot tell the moved lines from the changed ones. Bugs hide in exactly that mix.

The word

Engineers call this

refactorChanging how code is arranged without changing what it does. Users see no difference; the code becomes easier to read and change.

Change the shape or change the behavior, never both in one step. Run the same tests before and after a refactor, and expect them to pass with no edits.

Where this idea leads

Skills that encode it

  • principle-test-behavior-not-implementation pstackA good test survives a change to the internals that keeps every observable result the same, and fails when behavior breaks.
  • tdd Matt PocockTests verify behavior through public interfaces, so they survive refactors; refactoring stays out of the red-green loop.
  • principle-sequence-verifiable-units pstackEach unit is a before/after bracket: known-good state, one change, run the check, then proceed.