Do it manually: Refactoring is a human endeavor that requires a lot of thought, creativity and a subjective approach, according to Grosenbach. “You can’t ask a computer to rewrite an English sentence so that it is more poetic, readable and better-sounding,” he said. “It definitely involves humans.”
Ideally, Grosenbach says the person who wrote the code in the first place should be the one refactoring because it is the fastest path from the intent of code to the concise, clear communication of what the code does. “Often this is why big rewrites happen because developers who did not write the code originally get in there and try to figure out what it does and are completely lost. They can’t figure it out because it hasn’t been refactored very well or hasn’t been written very well in the first place, so people throw up their hands and decide to abandon it or just start from scratch,” he said.
According to Belshee, people often think of design as a write-time activity where they write new code and refactor it to make it clean. “Read time is just when it is a no-brainer and makes sense. If you have the right tools and approach, any time you are trying to read code and figure out what it does, the cheapest way to read it is to refactor it to make it legible and then read the legible thing,” he said.
“To read code, you do a simple loop: Read something, have an insight, write it down, report. As you understand small things then you can build understanding of large things.”
Having tests from the beginning ensures you are starting from a good known state and that your application is functioning correctly. “As you start doing your refactoring, you can run those tests, and as long as everything is turning green, you have the confidence that you haven’t adversely affected the application,” said Microsoft’s Schmelzer.
If you aren’t the developer who wrote the code, or if you are unsure if the code will make sense to other people, get a second opinion. “It’s good to sometimes have a peer review code if you don’t understand it or feel it’s too complicated, before embarking on refactoring,” said JetBrains’ Hariri. “Chances are, if you don’t fully comprehend the code, refactoring won’t make things better.”
Going beyond code reviews, developers can actually work in a pair-programming environment, according to Belshee. “It is possible to get sidetracked, especially in solo work. Pairs are less prone to get sidetracked because they keep each other on topic. But when you are working by yourself and trying to understand code, it is pretty easy to slip from a starting state of ‘I am trying to understand this code so that I can make this change,’” he said.
It is important to keep it as simple as you can. According to Belshee, developers often think skills such as test-driven development, advanced design skills, architectural awareness and knowledge of mocking are necessary for refactoring, but they are not needed and developers shouldn’t overcomplicate things for themselves with skills they don’t need.
How do tools come into play?
While many experts echo the same sentiment that tests should be in place to help developers refactor, Belshee believes there is a different approach.