Refactoring: Changing Structure Without Changing Behaviour
Refactoring changes internal structure while preserving observable behaviour. Small steps, relevant tests and code review help assess that preservation and locate problems. Passing tests support claims about their checks, not every possible input or effect.
What a learner can do afterwards
- Extract a function from a long block without altering any observable behaviour
- Rename and move a class in steps, keeping the code running throughout
- Distinguish behaviour-preserving restructuring from an intended behaviour change
1 · Read
Refactoring changes a program's internal structure while preserving its observable behaviour. Observable behaviour includes returned values, raised errors and effects such as printed output or file changes. File names and line counts may change if callers still receive the same promised behaviour.
As in the unit-testing lesson, passing tests establish only what they check. Run relevant tests before editing and after each small step. They provide evidence that tested behaviour stayed the same, not proof about every possible input or effect. Review the changed code and any uncovered behaviour too.
Small steps make changes easier to inspect and undo. Edit size alone does not define refactoring: replacing a whole block can preserve behaviour, but a larger change is harder to check. A bug fix or new feature changes behaviour and should be distinguished from the structure changes around it.
A forty-line billing function reads input, computes the bill and prints it. Extract one job into a helper without changing the input it receives, the result it returns or when its effects occur. Run the checks before extracting the next job. Check that the printed bill still matches the contract.
For a class rename, update its uses and check the program. For a move, update imports and check again. Either order can work; separating the changes helps locate a failure. Check public import paths too if other code is promised those paths.
If a check fails after a small edit, investigate before continuing. A failure may reveal changed behaviour, a broken import or an assertion tied to an internal detail. Undoing the latest edit can restore a known baseline while you inspect the cause. Do not change a valid expectation just to get a pass.
A bug fix may be valuable, but it deliberately changes behaviour. Separate it from refactoring when practical: first preserve the old behaviour while restructuring, then change the specified behaviour with suitable tests. This makes each change's purpose and expected results easier to review.
Preserve observable behaviour. Use small edits, relevant checks and code review. Separate intended behaviour changes from refactoring.
Original lesson, questions and flashcards written for this learning dataset.
2 · Watch
به انگلیسیTake it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.