Chapter 9. Refactoring Code

Whether or not you realize it, if you are like most developers, you are always refactoring code. Every time you change your code to reduce duplication or rename items for the sake of clarity, you are refactoring. Refactoring is simply putting a name to a common development task. The strict definition of the term is “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.” That is, refactoring does not add features to the application. Instead, it improves the general maintenance of the code base.

The time to refactor your code is as you are building it. This is when you are closest to the code and thus able to quickly make these maintenance-type changes. It is much harder to let the problems linger and come back to them later. Refactoring should be part of your everyday development approach.

Refactoring is also a key tenet of modern, agile development where your code base builds feature by feature to satisfy a series of tests. This can result in code that works wonderfully but does not look as though it was designed as a cohesive unit. It can create maintenance issues, duplicate code, poor conventions, and other issues. To combat these problems, you would be wise to go over the code base at frequent intervals after everything works fine. The goal is to improve the general quality of the code (remove duplication, create common interfaces, rename items, put things into logical groups, and so on) without risk.

Refactoring has been moved inside the code editor for 2015. It presents itself in the margin of the editor as a light bulb appearing as you need it. Refactoring has also been extended beyond C# to Visual Basic. These tools let you make changes to the code base without the concern of creating more problems than you are solving.