Programming.Refactoring History

Hide minor edits - Show changes to markup - Cancel

September 16, 2010, at 07:29 AM by OtherMichael -
Changed lines 2-3 from:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring (from



Added lines 8-10:

September 22, 2008, at 04:22 PM by OtherMichael -
Changed line 64 from:
June 10, 2008, at 04:20 PM by MichaelPaulukonis - objections
Changed lines 15-28 from:

Overcoming Objections

It is not uncommon for people ranging from the CEO to managers to HTML grunts to object to the concept of refactoring. The concern is expressed in many ways, but it usually amounts to this:


We don’t have the time to waste on cleaning up the code. We have to get this feature implemented now!


There are two possible responses to this comment. The first is that refactoring saves time in the long run. The second is that you have more time than you think you do. Both are true.


Refactoring saves time in the long run, and often in the short run because clean code is easier to fix and easier to maintain. It is easier to build on bedrock than quicksand. It is much easier to find bugs in clean code than in opaque code. In fact, when the source of a bug doesn’t jump out at me, I usually begin to refactor until it does. The process of refactoring changes both the code itself and my view of the code. Refactoring can move my eyes into new places, and allow me to see old code in ways I didn’t see it before


Changed line 31 from: - C#

to: - C#