One tool that junior developers often undervalue is refactoring. Since young developers probably haven’t worked on many projects where maintainability is important, it’s easy for them to overlook the importance of writing clean code. In this post, I’ll clear up some of the common misconceptions about refactoring.
1. “Refactoring is a waste of time.”
Junior developers often see refactoring as a waste of time. Since they’ve only worked on school projects where the code is written once and forgotten, they don’t understand the value of code that’s easy to read and maintain. From their perspective, refactoring doesn’t add any tangible value to the application.
But sooner or later in their professional careers, every developer ends up working with someone else’s old, first-draft code. The first time you waste several hours trying to decrypt something that could have been simple, refactoring will make a lot more sense.
Spend 15 minutes on refactoring your code to be more readable, and you could potentially save hours of other developers’ time.
2. “I can’t write better code than the senior developers on my team.”
It is easy for junior developers to assume that they cannot improve code written by more experienced developers. But while senior developers can be a reliable resource for knowledge and advice, they are not infallible. They are human too, and sometimes, they lazily write code. This means there are plenty of opportunities for you to improve code written by developers more senior than you.
If a piece of code that you didn’t write doesn’t make sense or reads badly, refactor it! If you’re still not sure, ask someone with more experience to confirm that your changes make sense. The worst-case scenario is that they disagree with you, and you learn from your mistakes. Otherwise, you will probably impress them and improve the quality of your code base.
3. “There’s no point in refactoring if I’m not optimizing the code.”
Is refactoring worth it—even if it doesn’t make the code run more efficiently? Most of the time, yes. While there are some programs that need to run as quickly as possible, most applications can sacrifice a few CPU cycles for the sake of maintainability.
If possible, you should fight the instinct to make your code faster at the cost of maintainability. Code that is fast but hard to understand is less valuable than code that is easily understood, and not quite as efficient in most cases.
It’s almost always the right choice to refactor code when you get the chance. Although it usually doesn’t pay off immediately, it will do so in the future when someone else has to understand your code.
If you would like to read more about how to refactor, I recommend Martin Fowler’s book Refactoring. It goes into more detail about the benefits and methods of refactoring.