There are many misconceptions among developers and development managers about refactoring. Perhaps a consultant used refactoring as an excuse to spend needless cycles reading blogs, or maybe a “refactoring” was blamed for a large swath of bugs found in a release. Regardless of the source, there are development shops that cower in fear or scream in terror when the word “refactoring” is uttered aloud.
The problem is they were frightened by something other than refactoring.
I hang out with developers around the globe at conferences, user groups, and sometimes just to grab a bite to eat. I enjoy discussing code and long walks on the beach. Okay, honestly, the sun is nothing compared to the warm glow of a computer monitor.
When I hang out with other developers, I like to talk shop. These conversations have convinced me there are mis-perceptions present in our field that should be corrected. So, I created this list describing what .NET developers should know about C# refactoring. I kept it to five key items for brevity, but you’re welcome to add to the conversation in the comments below.
Refactoring is code cleaning. Why not just call it code cleaning then? Because, as Martin Fowler describes it, refactoring is “a technique for cleaning up code in a more efficient and controlled manner.” He should know; he wrote the book. Guess what: whenever you make a change to the code to make it clearer, without changing the software’s functionality, you are performing a refactoring. Whether you’re renaming a variable to something more meaningful or removing duplicate code, you’re cleaning up the code for yourself and others to better understand.
It’s extremely easy to confuse refactoring and rewriting. Technically, you are changing code when performing refactoring, but the key is that you’re not changing the system’s functionality. Rewriting involves rethinking a problem and designing a new approach. By its nature, rewriting causes the system’s functionality to change in some manner.
I have worked in shops with dedicated refactoring iterations. It is commendable to take the time to clean up code, but dedicated iterations lead to refactoring being dropped as the deadline approaches. Besides, being told to refactor for days at a time will lead to rewriting the code instead of just cleaning it up. Make refactoring a continuous process instead. Don’t be afraid to clean up dirty code when you encounter it.
I take the previous statement back; do be afraid. Well, maybe not afraid, but definitely be wary if you do not have unit tests. These tests prove the functionality of individual components in your software. If a refactoring changes the functionality of the software, your unit tests will inform you.
This is the basis behind the paradigm from test-driven development: red-green-refactor. You write a test that should fail (red), and then add functionality for the test to pass (green). Finally, you refactor the code to remove duplication and clarify intent, and then you make sure the test still passes.
Time is valuable in our industry. Despite the savings you gain by having a clean code base, looming deadlines may cause developers to shy from the refactoring step. It still needs to be cleaned, but who has time to extract methods and such when a release is approaching?
Refactoring doesn’t have to be time-consuming and tedious. Many refactoring processes can be automated, and many languages have refactoring tools to do this. Since I am a .NET developer, I prefer to use Telerik JustCode to make refactoring fast and easy. JustCode provides for improved code performance, code readability and maintainability. It blends into Visual Studio, providing contextual hints and refactorings when I need them and without getting in my way. Efficiency and effectiveness are important for many developers. Find the tool that improves best for you.To try the one that works best for me, you can download a trial of JustCode. If you need a refactoring that isn’t included, the extensible API makes it possible to add it on. Leave a comment for your request, and I may code it for an upcoming refactoring article!
Chris Eargle is a Microsoft C# MVP with over a decade of experience designing and developing enterprise applications, and he runs the local .NET User Group: the Columbia Enterprise Developers Guild. He is a frequent guest of conferences and community events promoting best practices and new technologies. Chris is a native Carolinian; his family settled the Dutch Form region of South Carolina in 1752. He currently resides in Columbia with his wife, Binyue, his dog, Laika, and his three cats: Meeko, Tigger, and Sookie. Amazingly, they all get along... except for Meeko, who is by no means meek.