A Perspective of Codebase Mastery on Refactoring

We develop software to solve a problem, automate complex processes and improve efficiency. In other words, it is a tool for people to make their lives easier. Therefore, as developers our primary focus is to add functionalities and make sure they are working correctly.

But wait, some dirty developers waste their time to fix code that is already working as expected. How can you fix a code that is already correct. What is your goal you idiot? If it works, don’t touch it!

So many people tend to have this approach. If it is working, why bother improving it. It is a waste of time. Besides, you may break it. But is that really correct? In this story, I’ll try to explain why we (as developers) need code refactoring and why it is NOT a waste of time.

What Was I Thinking?

We all know that, developers do code refactoring to improve code quality or performance, remove code smells, and reduce code duplications. These are obvious reasons, no need to talk about them. But there is another benefit (and I believe it is the most important one) that I want to talk about. Mastering the code base.

We write thousands and thousands of lines of code in a software project. No matter how good we document our code, and our design decisions, it is impossible to remember the purpose of each and every line. Sometimes, we need to change a piece of code that we wrote a couple of months ago because the related requirement has changed, or a bug is found on the production, or it is broken as of a side effect of another change that is made on another piece of code (shouldn’t happen, but it does!). Have you asked yourself “What was I thinking while writing this?” I believe the answer is “YES” for most of the developers (if not all). The reason you ask such question to yourself is that, you haven’t spent time thinking about that piece of code for a very long time and as a result you forgot the purpose despite you are the author of it.

It is even harder when we need to change a code that is authored by another developer.

Mastering the Code

Understanding the code is the first step of refactoring. That’s why developers who spend more time on it, have a better understanding of the code. They constantly refresh their memories and that’s the key. As a result, they can easily make changes to the system when needed because they are able to see the big picture, not some independent pieces. Not good enough? How about the following items:

• Being able to maintain the code without the fear of breaking it
• Less time for fixing bugs
• Less time for making changes

Some developers spend hours to understand and solve bugs or making changes to the existing code while some others spend minutes. Why is that? Of course it is related to the complexity of the bug (or the change request), but this statement would remain true even if all the bugs on the world were on the same level of complexity. You may think that it is also related to the knowledge & experience level of the developers. I am not arguing that either. What I am trying to tell is this statement would still be true if all developers had the same knowledge & experience because I believe that, it’s also related to how well you remember the code.

When you force all developers to focus on feature development and do not support code refactoring, nobody will master the code base. Eventually the upper management and the product management will have a hard time when they want to make changes to the existing features, when some bugs are found on the production, even when adding new features.

When to Refactor?

I heard developers or managers many times saying that “our code is so messed up that it takes very long time to make changes, and while we are fixing bugs, we are introducing new ones. Let’s spare a sprint for refactoring”. OK, let’s spare a sprint for it, but where to begin? If that’s your approach, then I would agree that refactoring is a waste of time. It just doesn’t work like this.

The important thing about code refactoring is to criticize the code all the time and have specific improvements in mind (or in your notes). Only that way you will feel the need for refactoring even when you are adding a new feature, or fixing a bug. And only that way you will master your code base.

I am not saying you should forget about feature development or bug fixes, and do refactoring all the time. Of course, completing the issues “in time” is more important than code refactoring. After all customers don’t care how clean your code base is. What I suggest is to make refactoring be part of your development process. Criticize the the code that you touch within the scope of your task, realize code smells, duplications, unnecessary operations, and bad practices. If you don’t have enough time to apply the improvements that you have in your mind, note them down and apply them later when you are not in a rush.

The END

I personally find code refactoring similar to cleaning home or having a shower. It feels like you are getting rid of the dirts, isn’t it? If you don’t clean your house for a very long time, the dirt that you are living in will eventually kill you. I think the very same thing applies for software development. If you don’t refactor your code for a very long time, you will eventually have trouble while maintaining it.

This is my recent perspective on code refactoring and I would like to hear if you have different opinions . Thank you for reading this far.