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.

  1. Concepts
  2. Questions
  3. Sort and link
  4. 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 t to vatRate throughout 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 t to vatRate throughout the code

    Only the renaming leaves observable behaviour intact. Fixing a rounding, adding a field or removing a check change what the software does.

  • 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.