refactoring

Refactor code by making one small change at a time, then running tests after each change. This one-change-at-a-time discipline—rename, extract function, move function, or remove dead code—ensures behavior stays identical while improving structure. Commit after each tested change.

Refactoring improves code structure without changing behavior; it excludes style fixes, formatting, bug fixes, and new features. Focus refactoring on code smells like duplication, long methods, or unclear names identified by phrases like 'clean up' or 'extract.'

Use characterization tests—write tests that capture the current behavior before refactoring. These tests document how the code works now, then protect against accidental changes during refactoring. Test after every single change.

No. The one-change-at-a-time discipline requires completing one refactoring, testing it, and committing before starting the next. Batching changes obscures which change caused problems and violates the core refactoring cycle.

Look for duplicated logic, overly long functions, unclear variable names, dead code, or functions doing too much. Phrases like 'refactor,' 'clean up,' 'restructure,' 'extract,' 'rename,' or 'simplify' signal opportunities for one-step-at-a-time improvement.

Yes. Refactoring principles—one change, test, commit—apply universally. The specific techniques (extract function, rename, move) work across languages. Start with a small, isolated improvement and follow the discipline regardless of your tech stack.