Refactoring

Changing internal structure without intentionally changing observable behaviour. Almost everything called a refactor is something else, and the difference is what makes it safe.

Working code, a safety net, one small transformation, verify, repeat. The discipline is entirely in the size of the step and in never being more than one step from working.

Extract to give a meaningful concept a name, not to reduce a line count. The two motivations produce different code, and only one of them helps.

Pull out a module when a set of responsibilities has become cohesive enough to have its own reasons to change — and its own interface that hides them.

The highest value-to-risk refactoring there is, and the most neglected. A better name is a better model, and the cost is usually one command.

If a piece of logic spends its time reaching into another object's data, it probably belongs to that object. Moving it is usually the cheapest coupling reduction available.

Worth doing when the variation is stable, meaningful and repeated across several operations. Not worth doing to most switch statements, where the switch is clearer than what replaces it.

Bundle arguments that travel together and mean something together. Bundling them into a vague `Options` bag because there were too many is how a long parameter list becomes an untyped one.

Sometimes you have to change code whose behaviour nothing protects. The technique is a small number of provably-safe moves, used to buy a seam, used to get a characterization test in place.