The refactoring process
Refactoring without changing behaviour: test safety net, small steps, one refactoring per commit; technical debt and its quadrants; refactor or rewrite, gradual replacement.
- 21 cards
- 4 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Concepts
- Questions
- Sort and link
- Scenarios
A few cards from the deck
Refactoring: what is it?
Show the answer
A change to the internal structure of code to make it clearer and easier to change, without altering its observable behaviour.
If behaviour changes, it is no longer refactoring: it is an evolution or a fix. The proof is kept with tests that pass before and after.
Among these changes, which is a refactoring in the strict sense?
- Renaming a variable
ttovatRatethroughout the code - Fixing the rounding of an invoice total that lost a cent
- Adding a 'phone' field to the signup form
- Speeding up a query by removing a permission check
Show the answer
Renaming a variable
ttovatRatethroughout the codeOnly the renaming leaves observable behaviour intact. Fixing a rounding, adding a field or removing a check change what the software does.
- Renaming a variable
A rule of discipline: never mix a … and a behaviour … in the same commit.
Show the answer
A rule of discipline: never mix a refactoring and a behaviour change in the same commit.
Kept apart, commits are easy to review and revert: if a test breaks, one knows whether the cause is structure or behaviour.
Test safety net: what is it?
Show the answer
A set of automated tests that pass before a refactoring and must pass after, proving that observable behaviour has not changed.
Without it, one cannot know whether something was broken. Hence the rule: no net, no refactoring; start by laying tests.
A commit is titled 'billing refactoring'. In its diff, besides a renaming, the line
-if total > 100:is replaced by+if total > 150:. What follows?- Nothing wrong: changing a constant remains a refactoring as long as all the existing tests still pass
- The commit is valid provided its title is renamed to 'fix' in the repository history
- Adding a test for the new threshold and keeping a single commit for all the work is enough
- The commit changes behaviour: the threshold belongs in a separate commit, as a behaviour change
Show the answer
The commit changes behaviour: the threshold belongs in a separate commit, as a behaviour change
A total of 120 gave one result before and another after: observable behaviour moved. Filing it all under 'refactoring' hides the risk from reviewers; the two are always separated.