24 — Automated Refactoring & Program Transformation

Driving question: What does an automated refactoring system need to prove—or at least check—before changing code?

Learning objectives

• Model refactorings using preconditions and transformations.
• Differentiate IDE refactoring, recommendation, and autonomous transformation.
• Explain semantic risks from language features.
• Design rollback, validation, and human-review mechanisms.

Transformation pipeline

graph LR
  A[Parse / Analyze] --> B[Find candidate]
  B --> C[Check preconditions]
  C --> D[Transform]
  D --> E[Compile / Type-check]
  E --> F[Test]
  F --> G[Quality evaluation]
  G --> H[Accept / Roll back]

Safety layers

An automated system may use several imperfect but complementary safety checks:

• static semantic preconditions;
• successful parsing/type checking/compilation;
• test-suite preservation;
• differential testing;
• behavioral traces;
• API compatibility checks;
• developer review.

Passing tests is evidence, not proof, unless the tests fully characterize the relevant behavior.

Design / research exercise

For one non-trivial refactoring (Move Method, Pull Up Method, Extract Class, etc.), define candidate-selection criteria, semantic preconditions, transformation steps, and post-transformation validation.

Suggested reading

• Opdyke and subsequent automated-refactoring literature.
• IDE refactoring-engine documentation as implementation evidence.