How to make refactoring less "destructive"? [closed]

Question

Currently performing a fairly major refactoring of an application due to a very late major requirement change.

I always feel when I'm doing this sort of thing that I'm not approaching it in a very disciplined manner. My application is likely to go days/weeks at a time in a state where it either doesn't build or requires commenting out huge swathes of code just to get it to compile.

I don't like checking into source control in this state so I often feel I have no fall back if I make a big mistake. I am literally right now destroying my application, and I'm holding 100 different threads in my head. Like one of those people you read about who takes their car engine apart out of curiosity and then realises they have no idea how to put it all back together again.

Are there any good resources out there which discuss how to approach refactoring in a more incremental and less destructive manner? Can anyone offer any advice? Or does everyone feel like this?

Answer 1

What you describe is in fact not refactoring.

Refactoring is a disciplined effort to improve the design of the code without changing its functionality, done in small - even simplistic - steps, safeguarded by unit tests, which ensure that the system is functional after each step. Moreover, it is typically done in small increments over a longer period of time, not in one big whoosh.

This is not to be overly zealous about anything, just to clarify the terms :-) There is less chance of misunderstanding and communication problems when we understand the same words the same way.

Of course, if you have the time to do a lot of refactoring at once, all the better! But before you embark on such an effort, you absolutely need to build a good set of unit tests which cover - ideally - all the functionality in the code parts you are about to change.

Since you are talking about a "major requirement change", it is not clear whether what you call "refactoring" is actually implementing new functionality or only improving the design to prepare for the introduction of new functionality. I strongly recommend to keep the two phases separate: refactor first without changing the existing functionality, to make your design more open to extensions at the right places, which then allow you to incorporate the desired functional changes more easily.

The Refactoring book linked by @Eric is fundamental; I would add Refactoring to Patterns by Josh Kerievsky, which is about the practical application of refactorings.

Answer 2

You need a good unittest suite to ensure you don't break what's already working. There's also a good book from Martin Fowler on this subject: Refactoring: Improving the Design of Existing Code

I would also recommend abstracting the part of the code you intend to refactor and still provide the old implementation for everyone else while you can access the new code you're writing so you can still benefit from source control.

Using a distributed source control system would also let you commit without disrupting others work.