Refactoring ist die strukturierte Veränderung von Code, ohne sein nach außen sichtbares Verhalten zu verändern. Das Ziel sind besserer Aufbau, höhere Lesbarkeit, geringere Komplexität und einfachere Erweiterbarkeit – bei gleichbleibender Funktionalität.
Klassische Refactorings sind unter anderem "Extract Method", "Inline Method", "Move Method", "Replace Conditional with Polymorphism" oder "Introduce Parameter Object". Sie werden idealerweise in kleinen Schritten und mit grünen Tests nach jeder Änderung durchgeführt; IDEs wie IntelliJ, Visual Studio und VS Code bieten viele Refactorings als One-Click-Aktionen.
Einsatzzweck ist die kontinuierliche Pflege technischer Qualität. Refactoring ist Bestandteil agiler Praktiken (XP, TDD), der Boy-Scout-Rule und vieler Code-Review-Kulturen. Ohne regelmäßiges Refactoring sammelt sich technische Schuld, was Modernisierung und Erweiterung mittelfristig immer teurer macht.
Der Begriff wurde 1992 von William Opdyke in seiner Dissertation systematisch beschrieben und 1999 durch Martin Fowlers Buch "Refactoring: Improving the Design of Existing Code" einer breiten Öffentlichkeit zugänglich gemacht. Eine zweite Auflage erschien 2018, mit aktualisierten Codebeispielen und ergänzten Mustern.
In der Praxis grenzen sich gute Teams klar davon ab, "alles umzuschreiben" und nennen das Refactoring. Wichtig ist die Unterscheidung zwischen Refactoring (Verhalten unverändert), Restructuring (Architektur ändert sich) und Rewrite (Verhalten und Code ändern sich) – Verwechslungen führen oft zu Erwartungsmissverständnissen mit Stakeholdern.