ALM Practices Part 7: Refactoring

What is it?

A mindset and practice that requires you to continuously reevaluate a region of code each time you make a change. In essence, you need to look at the code related to your changes and reconsider whether the original solution is still the best solution accounting for the information you currently have (and did not have at that time). Refactoring is a core practice of the Test Driven Development.

Why would you do it?

• Because, unfortunately, experience has proven that is virtually impossible to design a foundation or architecture that we never have to chance anymore. So in reality and in most situations, software is created incrementally by adding new bits and pieces on top of each other without reconsidering its foundations.
• Because any technical solution, both on an architectural level or at code level, is based on the knowledge you have at that point. Practice has proven that this knowledge improves over time and often becomes more focused, but is difficult to predict beforehand.
• Because of advancing insight it is possible that certain domain concepts (such as those part of the Ubiquitous Language) have been refined or renamed, and you want to make sure your code reflects those changes that all time.
• Because if you apply refactoring rigorously, you can start a project with Little Design Up Front instead of the infamous Big Design Up Front (can you predict the future?). Refactoring keeps your code base in good shape, so it’ll be easier to adapt your system or product to new requirements or technical changes.

What’s the bare minimum you need to do?

• Replacing obscure or complex code with more simpler code that complies with common design principles and design guidelines.

What’s the usual thing to do?

• Rewrite redundant and/or similar code so that you never have to apply the same change to multiple blocks of code, or, in other words, be DRY (Don’t Repeat Yourself).
• Remove unnecessary or unused code (including commented-out code).
• Considering the Single Responsibility Principle, move code that is at the wrong place in the code base.
• Remove unnecessary dependencies between unrelated classes.
• Rewrite code to comply with your coding guidelines and coding layout rules.

How do you do that?

• Apply Test Driven Development because it promotes choosing the simplest working solution possible and includes refactoring as one of its basic steps.
• Uphold to The Boy Scout Rule. Always, and with that I mean always, make sure that each and every source control check-in leaves your code base in a better shape than it was before.
• Keep the A4 cheat sheet of the Coding Guidelines for C# 3.0 and C# 4.0 close to continuously remember yourself of its most important guidelines.
• During a review, not only check that a block of code is functionally correct and uses the right layout, but also try using a high-level view to see whether that block of code is still at the right spot, or needs refactoring.
• Check that the name of a type or member is still covering its purpose.
• Print out the ReSharper Keymap and learn yourself the keyboard shortcuts for its many refactoring features.
• Make sure you use ReSharper’s Visual Studio Keyboard Scheme so that other developers will not run into issues when you are pair programming with them.
• Also include your automated unit tests when refactoring your code. Unit tests are first class citizens in your code base, and must of top-notch quality at all time.
• Use the complexity of your unit tests as a measure of quality. If they are difficult to understand or anything other than small, changes are that the tested class (or subject-under-test) is either too complex or has too many responsibilities.
• Consider using Clone Detective for Visual Studio to analyze your code base for duplication. It’s a free add-on for Visual Studio that will detect similarities in code constructs and can give you a quick analysis of your duplication.
• Consider using the Wall of Pain principle to keep track of your major architectural or technical issues and have a controlled and transparent way for fixing those.
• Seriously consider reading Robert C. Martin’s (a.k.a. Uncle Bob) Clean Code and Steve McConnell’s’ Code Complete. Both books provide very valuable guidance and background information on how to create high quality software.