A very large part of all the code that programmers work on exists already. Even on the .NET platform, code has been written now for almost ten years. More importantly, a large part of the code that was written in the C# language isn’t really new code. It’s new in that it was written from scratch in C#, but it was following the exact same ideas that the programmers used before they started writing C# code. These are the basic ideas of object oriented systems, patterns ranging from simple class hierarchy structures to enterprise-level multitier data exchange, ideas that were favored on platforms like MFC, Java, Delphi, and many others.
Refactoring — that is, the process of making structural code changes to promote reuse and maintainability — is a necessity for many reasons. Every programmer refactors continually, which can be a healthy evolutionary process that leads to better software quality over time. Modern software development methodologies such as Agile approaches favor refactoring as a prescribed technique to be used during the development cycle. “Red, Green, Refactor” is sometimes called the mantra of test-driven development (TDD).
The core of refactoring is the idea of making changes to existing code without changing the outcome of that code. You can look at this from far away or close up, and the definition may change a bit. While you are refactoring the content of a single method, for example, the outcome you’re aiming not to change may be the return type and ...