What Are the Key Insights of Refactoring?

Many people�s reaction to refactoring when first exposed to it is �so what?� This is just �tidying up� the code, something that programmers have been doing for almost as long as programmers have existed. Certainly, to some extent all that Martin Fowler did when he published Refactoring was to catalog techniques that developers have been using for years.

But there�s more to refactoring than just a catalog of useful techniques. It relies on Fowler�s two key insights:

� Modifying existing code can be carried out safely only with the safety net of a comprehensive suite of unit tests.

� We should never attempt to refactor the code at the same time as modifying its behavior.

In other words, you can modify the behavior of the code, or you can refactor it. You should never attempt to do both at the same time.

Upon reflection, it�s easy to see why this is the case. Imagine that you attempt to modify both the structure of your code and its functionality at the same time, and after doing so one of your tests fails. This might indicate that you made a mistake when modifying its structure. Or it might be an expected result of the change in functionality. It�s difficult, however, to be sure which. The more complicated the change in functionality or structure, the harder it is to be certain.

By doing only one or the other, you avoid this issue entirely and can forge ahead with potentially far-reaching refactorings involving dramatic changes to the code with confidence.

Source of Information : Paul Butcher - Debug it Find repair and prevent bugs