How to refactor code safely using small steps and tests

The most dangerous refactor is the one that touches 20 things at once. Refactoring safely means one change at a time, tests after every change, commit when green.

If you don't have tests for the code you're refactoring, write them first. These are called characterization tests — they don't test what the code should do, they capture what it currently does.

// Characterization test — captures existing behavior before refactoring
test('processPayment returns null for inactive users', () => {
  const inactiveUser = { isActive: false, balance: 100 };
  expect(processPayment(inactiveUser, 50)).toBe(null);
});

With that test passing, you can refactor with confidence. If the test breaks, you changed behavior — stop, revert, and try again more carefully.

The boy scout rule: leave code cleaner than you found it. You don't have to refactor entire files — just the part you're already touching. Rename one bad variable. Extract one method. Delete one noise comment. Do this consistently and codebases get better over time without dedicated refactoring sprints.

For large refactors — replacing an entire module or rewriting a critical path — use a parallel implementation strategy. Build the new version alongside the old. Use a feature flag to switch between them in production. Once confident in the new version, delete the old one.

if (featureFlags.useNewPaymentProcessor) {
  return newPaymentService.process(order);
} else {
  return legacyPaymentService.process(order);
}

This approach lets you ship and validate incrementally without a risky big-bang cutover.