Foundations — Refactoring — code smells, common refactorings (extract method, rename, etc.)

Before you can trust the parent note, you must own every word it silently assumes. Below is every symbol, term, and notation the topic uses — each with a plain meaning, a picture, and the reason the topic needs it. We build them in an order where each rests on the one before.

0. What even IS "code"? (the atom)

Picture a function as a machine with a slot on the left (inputs go in) and a chute on the right (output comes out).

Look at the figure: the teal box is the function. You do not see the gears inside — you only see what goes in and what comes out. That "only see in/out" idea is the whole game, so hold onto it.

1. Behaviour — the thing we must NOT change

Two functions have the same behaviour if, for every input you could feed them, they hand back the same output.

In the figure, two differently-built machines (different gears inside) produce the same output for the same input. To an outside observer they are indistinguishable. Refactoring turns the left machine into the right machine — gears rearranged, output untouched.

2. Structure — the thing we DO change

Picture the gears inside the box in Figure 1. Rearranging gears = changing structure. If the chute output is unchanged, behaviour is preserved.

3. Tests — how we see behaviour

We claimed behaviour must stay identical. But behaviour is invisible — you can't stare at gears and know the output is unchanged. We need a measuring instrument. That instrument is a test.

In the figure, each test pokes the machine with one input and compares the chute's output to a known-good answer. Green = matched (PASS). Red = mismatch (FAIL).

See Unit Testing for how these tests are actually written.

4. The arrow $⟹$ — "leads to / implies"

The parent's safety rule uses $⟹$. This is not multiplication or an arrow you draw — it's a logic word.

5. $f(\text{code})$ — a transformation

Picture $f$ as a "tidy-up robot": code goes in messy, comes out reorganised, gears equivalent.

6. Code smell — the warning notation

The figure maps three example smells to the pictures they evoke:

• Long Method — one giant box you can't see the top and bottom of at once.
• Duplicated Code — the same gear stamped in two places; fix one, forget the other.
• Magic Number — a bare literal like 0.0825 with no label saying what it means.

A smell tells you where to point a refactoring $f$; it does not force you to act (the Technical Debt you carry might be affordable for now).

7. The vocabulary of "why refactor"

These are plain-English concepts the parent leans on. Each links to a fuller vault note.

Prerequisite map

Read top to bottom: you need code before behaviour vs structure; you need behaviour before tests; tests plus the if-then arrow plus a transformation give the safety invariant; smells tell you where to apply the refactorings. Everything funnels into the parent: the Refactoring topic.

Equipment checklist

Cover each answer, then reveal to self-test your readiness.