Refactoring Guide

Refactoring in CodeGraph is about changing code without losing control.

The goal is not “make it prettier”. The real goal is:

  • reduce risk;
  • reduce duplication;
  • remove dead or fragile parts;
  • keep the rest of the system understandable.

When to Use It

Use refactoring analysis when you want to:

  • find dead code;
  • find duplication;
  • identify overgrown functions or modules;
  • estimate the blast radius of a cleanup;
  • prepare a safer change plan before editing.

The Useful Sequence

In practice, good refactoring usually follows this order:

  1. understand the area;
  2. measure impact;
  3. find risky dependencies;
  4. split the work into safe steps;
  5. review the result.

CodeGraph helps with every step.

Best Entry Points

Common starting paths:

  • /onboard to understand the subsystem;
  • /explain <symbol> for a focused reading pass;
  • refactoring-oriented scenario flow;
  • /review after the change is ready.

Why Sessions Matter Here

Refactoring is rarely one-shot work.

It often moves through:

  • discovery;
  • planning;
  • editing;
  • review;
  • follow-up fixes.

Keeping the same session means the reasoning and evidence do not reset each time.

What Good Refactoring Output Looks Like

A strong result should tell you:

  • what is safe to change first;
  • what depends on the target area;
  • what can be removed;
  • what should be split or simplified;
  • what needs another pass of review afterward.

Common Mistake

The biggest mistake is refactoring with stale context.

If project memory is old, old design notes can pull you in the wrong direction. That is why lifecycle state matters:

  • use current by default;
  • treat needs_review carefully;
  • keep deprecated out of normal retrieval.