Finally on Christmas holidays, I started watching the Pluralsight course Refactoring Fundamentals by Steve Smith which has been released only days ago. To be honest, I haven’t made it through the entire eight hours lasting course yet, but what I’ve seen inspired me to write down my own refactoring experience.

Let me start with these words I recently posted on Twitter:

What most developers don’t know: Refactoring isn’t (only) for bad programmers or bad code. It’s a fundamental discipline in software development.

In this blog post I am going to explain what I mean by this sentence and what you should know about this software craftsmen discipline.

What is legacy code?

First of all, I have to define what I am going to call “legacy code” in this article. The term legacy code means code which does not follow the SOLID principles, TDD and refactoring in general.

This means, you can also write legacy code within an entirely new project, if you don’t follow these principles and other things written in this article. Be sure to avoid that.

Why do we have to deal with legacy code?

It is pretty important to know why we have to deal with legacy code. It makes life much easier if we know why this is the case and what’s gone wrong.

Hopefully you’ll sometimes reach the point where you have to deal with an existing, over many years growing code base, simply because you develop a successful software.

If the project would fail or your product would be stopped, you won’t have to deal with legacy code, but this means you’ll lost your job some day, because the employer cannot pay your salary anymore. This is typically not exactly what you want.

What is refactoring?

Refactoring means changing pieces of your code base without adding new features or fixing a bug. The goal is to improve design, maintainability, readability and extensibility of your code.

You usually use some tools like ReSharper to help you refactoring. Using such a helper means doing less manual work and having a great result in a short period of time.

Which are the most common refactorings?

There are many, many well known refactoring practices. There are entire books about this topic. Clean code from Uncle B. Martin includes some refactoring techniques for example. Check out my digital bookshelf.

Some of the most common refactorings include:

• Extract method
• Extract class
• Encapsulate field

There is also a really well made webpage called SourceMaking about this topic.

How should a standard development cycle look like?

People are very happy if they can start a new project. There is no existing code to care about and they can use the libraries they want. At least, if the employer let them choose their tools. So developers start developing very fast in the first few days or months of the project.

But what happens over time? After 12 or 24 months? Or even years later? Be sure to develop your code with short cycles like these:

1. Writing

Writing not only means writing code to solve business needs. It also includes writing (unit) tests and doing all other stuff required while developing good software.

2. Testing

Testing means that you should be sure to have code which runs as expected. This means that your code is tested by unit tests and that it works. Maybe you have some integration testing or manual testing involved in addition.

3. Refactoring

Once you’re sure your code works, you can start refactoring. Try to simplify your code. Maybe you can rename something to make it more clear for the next (maybe you) developer reading this particular code fragment. Does it satisfy yourself? Well commit your changes and restart the cycle at step one.

Be sure to stick to this cycle. In my opinion this is the most important concept of Test Driven Development (TDD). The result has inevitably to be a clean and tested code base which allow you to work with it in an convenient way.

How do we avoid legacy code?

The goal of a professional software developer is to provide a consistent, maintainable, extendable and readable code base. Okay, you also have to make sure your product supports the users business case, but this is a thing not only professionals do right.

So if you want to have this great code base you like working with, you should follow the development cycle described above. Working this way saves you time and money in the long run.

Last but not least, follow the boyscout rule which says:

Always leave the code base cleaner than you found it.

Conclusion

Refactoring is really important when you’re involved in high quality or so called professional software development. I hope you gained some insight behind the concepts and are willing to improve your knowledge about this topic.

If you’re interested in more details about refactoring, I would recommend reading Clean Code from Robert C. Martin or visiting SourceMaking.com or any other website dealing with this topic in more depth.

Please share your experience and let me know about your thoughts in the comment field.

Further readings

• When should you refactor? by Steve Smith

Claudio Bernasconi

I'm an enthusiastic Software Engineer with a passion for teaching .NET development on YouTube, writing articles about my journey on my blog, and making people smile.