At a micro level, developers refactor their code on a daily basis, whether it is changing a variable name or method name, or moving the location of a functionality to a more logical location as the codebase evolves. “At this level, developers are really motivated primarily around understanding and making it easier for themselves and other engineers on the team to see what the code is doing and be able to walk into it and contribute quickly,” said Schmelzer.
At a larger level, the entire project needs to be rethought (like how it was for the travel industry). This type of architectural refactoring tends to happen more on a product cadence, according to Schmelzer.
Large-scale refactoring is also being seen more with the recent movement toward microservices, forcing developers to change their thinking (and code) from one monolithic application to a dozen or more apps that are focused on separate tasks, according to Pluralsight’s Grosenbach.
He added that the best way to refactor is to do it in smaller increments, and to start as early as possible to make it easier for developers going forward. “The biggest thing to note is that refactoring gets harder the longer you put it off, so it is better to do it often and better to have it part of your regular workflow,” he said.
What are some best practices?
Once businesses and teams understand the value they are going to get from refactoring, there are some best practices experts recommend they follow.
Know the basics: Understand what refactoring is and how to do it before you even attempt it. Also, understand exactly what the code is doing before you start changing it. “It is important to step back and spend time reading the code, thinking about it, understanding it, and making sure you have a good grip on what is going on before you charge in and start modifying things,” said Grosenbach.
Have empathy: It might sound like a strange skill for software development, but Grosenbach says having empathy allows the developer to get out of his or her own head and look at the code as if he or she weren’t the person who wrote it. “Can I think about how these statements of code are going to be read and understood by other people?” he said.
Be curious: Developers should have the desire to poke around and figure out how a codebase works. “It’s an unwillingness to do something the dumb way just because you already know that way,” said Industrial Logic’s Belshee.
Be familiar with the language: Developers should know the basic idioms and programming constructs of their language. “This doesn’t need to be extensive; reflective design will teach it to you as you go,” said Belshee.