Book Image

Refactoring with Microsoft Visual Studio 2010

By : Peter Ritchie
Book Image

Refactoring with Microsoft Visual Studio 2010

By: Peter Ritchie

Overview of this book

Changes to design are an everyday task for many people involved in a software project. Refactoring recognizes this reality and systematizes the distinct process of modifying design and structure without affecting the external behavior of the system. As you consider the benefits of refactoring, you will need this complete guide to steer you through the process of refactoring your code for optimum results.This book will show you how to make your code base more maintainable by detailing various refactorings. Visual Studio includes some basic refactorings that can be used independently or in conjunction to make complex refactorings easier and more approachable. This book will discuss large-scale code management, which typically calls for refactoring. To do this, we will use enterprise editions of Visual Studio, which incorporate features like Application Performance Explorer and Visual Studio Analyzer. These features make it simple to handle code and prove helpful for refactoring quickly.This book introduces you to improving a software system's design through refactoring. It begins with simple refactoring and works its way through complex refactoring. You will learn how to change the design of your software system and how to prioritize refactorings—including how to use various Visual Studio features to focus and prioritize design changes. The book also covers how to ensure quality in the light of seemingly drastic changes to a software system. You will also be able to apply standard established principles and patterns as part of the refactoring effort with the help of this book. You will be able to support your evolving code base by refactoring architectural behavior. As an end result, you will have an adaptable system with improved code readability, maintainability, and navigability.
Table of Contents (17 chapters)
Refactoring with Microsoft Visual Studio 2010
Credits
About the Author
Acknowledgement
About the Reviewers
Preface
6
Improving Class Quality
9
Improving Architectural Behavior

What is refactoring?


Although the task of refactoring has been around for some time, and the term refactoring and the systematic approach associated with it have also been around for a long time; Martin Fowler and all were the first to popularize refactoring and begin organizing it more systematically.

Refactoring is a very broad area of software development. It could be as simple as renaming a variable (and updating all the uses of that variable), or it could refer to breaking a class that has taken on too much responsibility into several classes, like implementing a pattern. Refactoring applies to all complex software projects that require change over time.

 

A pattern is a [description of] a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

 
 --Christopher Alexander

Refactoring is changing the design of a software system without changing its external behavior. Changes to internal structure and interfaces that don't affect the system's external behavior are considered refactoring.

The term refactoring was coined by William Opdyke in what seems to be an evolution of factoring. Factoring was a common term used in the Forth programming language (and mathematics) to mean decomposition into constituent parts. The term refactoring has been around since at least the early 1990's. Few developers would argue that refactoring isn't something they do on a day-to-day basis. Although refactoring is a fairly simple concept, many programmers don't associate changing code without changing external behavior as being refactoring.

Refactoring has been an integral part of software development in the Extreme Programming (XP) methodology since Kent Beck introduced it in 1999.

Note

Kent Beck introduced XP in the book Extreme Programming Explained circa 1999.

XP mandates a Test-Driven-Development (TDD) process, where only enough code is written to implement a single feature and to pass at least a single test. The code is then refactored to support implementing another feature and pass all the existing tests. The new feature is then implemented and passes at least a single new test and all current unit tests. Extreme Programming also mandates continuous refactoring. We will discuss the importance of tests when refactoring in Chapter 3.

Some of the first tools to support automated refactoring came out of the Smalltalk community. The "Refactoring Browser" was one of the first user interfaces that provided abilities to refactor Smalltalk code. Now refactoring tools are commonplace in almost all programming language communities. Some of these tools are stand-alone; while some are add-ins to existing tools; while some refactoring abilities are built into other tools and applications where refactoring isn't their main purpose. Visual Studio®® 2010 fits in the second two categories. Visual Studio®® 2010 is an integrated development environment (IDE) designed specifically to allow developers to perform almost all the tasks required to develop and deliver software. Visual Studio® ®, since version 2005, has included various refactoring abilities. Visual Studio®® has also included extensibility points to allow third-party authors to write add-ins for it. Some of these add-ins have the purpose of giving users of Visual Studio®® 2010 specific refactoring abilities. Add-ins such as Resharper, Refactor! Pro, and Visual AssistX add more refactoring abilities for Visual Studio® 2010 users.

Refactoring has become more mainstream with Visual Studio® users in the past few years because of the built-in automated refactoring abilities of many IDEs, including Visual Studio® 2010. It's now almost trivial, for example, to rename a class in a million line software project and update dozens of references to that class with a few mouse clicks or keystrokes. Before the support for this simple refactoring came about, this problem would have involved searching for text and manually changing text or using a brute force search-and-replace to replace all instances of the class name and then rely on the help of the compiler to tell you where replacements weren't actually a use of the class name. While it's almost unheard of for IDEs to not have some sort of (at least rudimentary) simple automated refactoring abilities, developers will always have to manually perform many complex refactorings (although they may consist of some simple refactorings that can be automated).

Without automatic refactoring abilities and tools, developers feel friction when performing simple refactoring. Changing the order of parameters in a complex million-line software project, for example, is tedious and error prone. Encountering a spelling mistake in the name of a method that is referenced by dozens of other methods in dozens of other files is time-consuming. Without automated tools, our maintenance problems cause even more friction; simple tasks like changing the order of parameters or fixing spelling mistakes are simply avoided. This prevents a code base from improving in its maintainability and it becomes even more fragile and even more likely to be neglected (have you ever tried to find a specific method with text search only to find out someone misspelled it?)

It's the ease with which simple refactorings can be performed that has elevated "refactoring" in to the lexicon of almost every programmer. Yet, there is so much more to the act of refactoring than just simple refactorings that can be accomplished automatically by software.

The common thread in all refactoring is the goal of the refactoring. The goal can be as simple as making the code easier to read and maintain, or to make the code more robust; or the goal may be as complex as improving componentizing code modularity to make it more decoupled and to make it easier to add new behavior. But, systematic refactoring is the acceptance that the act of writing software is not atomic; it cannot be done in a single step and will evolve over time as our understanding of the problem domain improves and/or our customer's understanding of their needs is discovered and communicated.