Table of Contents


Refactoring is the process improving the structure of the code without changing its externally observable behaviour.


How it works

Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. –

for each desired change, make the change easy (warning: this may be hard), then make the easy change – Kent Beck

Refactor Type Description
TDD Refactoring is part of the Red-Green-Refactor cycle of TDD. After the "Make it work" step, the "Make it clean" step follows explicitly.
Boy Scout Rule Code smells are fixed right away in little steps when they are identified.
Comprehension After a hard time understanding a piece of code, the heureka moment is captured to make it easier next time for someone else.
Preparatory Changes of the code structure before the new feature to make the work easier.
Planned Code structure improvements which are part of the project plan. This should be an exception.
Long term Working towards a vision how the code should look like. Ideally in little steps without making it part of the project plan.
Jürgenizing Oliver Gierke - Jürgenized

Also see "Workflows of Refactoring" from Martin Fowler (talk, infodeck)


Duplicate and abstract