0202.sdt-refactoring

A software developer’s job is never done. They don’t always get their code right on the first time, and it doesn’t always look pretty at first glance. Developers have to constantly modify, improve, and clean up their codebase to make it more readable and maintainable.

“Software development is like writing a novel,” said Geoffrey Grosenbach, vice president of innovation at Pluralsight, a provider of online professional software development training. “You write a first draft and you can see where it is going, but it is not cleaned up yet so you go back and you edit that novel a little more, and a few more times until you have a completed book. Refactoring is this idea of treating software as a draft, going back through the code, rewriting it to do the same thing it was always doing, but improving it so it is more useful to oneself and to other people who are going to work on it later.”

Developers want code to be pretty easy to work with and pretty easy to understand, but as code gets older and older, they are forced to revisit and update that code. Software is increasingly becoming more important to the businesses as a whole regardless of the industry, and developers need to find ways to take advantage of their existing apps and codebases, according to Jay Schmelzer, director of product management for Visual Studio at Microsoft.

Those who embark on a refactoring journey will have to understand the business goal they are trying to achieve, be able to detect when refactoring is necessary, and have the skillsets to successfully complete a code transformation.

When should you refactor?
Refactoring helps reduce the unessential complexity and get down to the essence of your code, but how do you know when your code includes that unnecessarily complexity? If you are reading your code and it takes you more than four seconds to understand exactly what the code does, then you need to refactor it, according to Arlo Belshee, senior legacy code consultant for Industrial Logic, a software development training provider.

“It is a read-time thing,” he said. “If you ever find yourself reading code instead of scanning it, it needs refactoring because you should always be able to scan it.”

(Related: What to do before refactoring your monolith into microservices)

According to Belshee, a developer’s largest source of frustration comes from not being able to get a computer to do what they want it to. Often, developers get overwhelmed with this frustration, and there is an appeal to starting from scratch. Grosenbach said developers should resist this urge. “Software takes a lot of work and a lot of coordination with a lot of people; if we just throw it out, we lose all the knowledge we gathered when we wrote that software,” he said.

About Christina Cardoza

Christina Cardoza, formerly known as Christina Mulligan, is the Online & Social Media Editor of SD Times. She covers agile, DevOps, AI, and drones. Follow her on twitter at @chriscatdoza!