Question

Having read Fowler’s ‘Refactoring’ for a while, I still often catch myself thinking ‘I should have done this in smaller steps.’ — even when I did not broke my code.

Refactoring in small steps is safe, but cost time. It’s a trade off between speed and risk — I try to be strategic in choosing the way how I am refactoring.

Nevertheless: Most the time I am doing refactorings in larger steps. If I took some of Fowler’s ‘Mechanics’ section and compare how I am working, I maybe find that I often leap two or five steps forward at once. This does not mean that I am a refactoring guru. My code maybe stay for 5 – 60 minutes broken or uncompilable.

Do you refactor in smaller steps and try to produce unbroken code in shorter frequencies? And: Are you successful in doing this?

Answer 1

Martin Fowler seems to lean towards the small, gradual refactoring approach. However, after reading his book he does occasionally make some drastic steps but only with unit tests to back up the code.

Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which ‘too small to be worth doing’. However the cumulative effect of each of these transformations is quite significant. By doing them in small steps you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring – which allows you to gradually refactor a system over an extended period of time. – Martin Fowler