Start your free trial
Book a Demo
Sign in

When Is The Right Time To Refactor Your Code?

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Run-through

By GITENTIAL TEAM

What does code refactoring mean?

The official definition – Code Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior.

It’s like housekeeping – to keep your home, office, store, warehouse… or software code clean and with everything in its proper place. Imagine being in a rush to make breakfast every morning, but never taking time to clean the dishes. At least three things eventually happen. You’ll run out of clean dishes, your kitchen will smell, and it’ll attract… BUGS!

Code refactoring is a lot about cleaning your code and keeping it clean. It doesn’t add anything to the code. As it doesn’t introduce new features, code refactoring is often set aside in favor of work on new features and releases with tight deadlines. As all code rots over time, it accumulates as technical debt making the work you have planned more difficult and take longer. This throws off your work estimates, increases costs, can cause deadlines to be missed, and reduces developer morale.

When Should You Start Refactoring Your Code?

Before you can refactor code it is essential for you to be reasonably familiar with the code and have sufficient (80+%) code coverage for it. This may require you to setup or write automated tests in advance. In Agile and Test-Driven Development (TDD) teams code refactoring is a continuous process. Generally though, it’s also standard practice to always leave the code you’re working on better than you found it. Here, we define six situations where you will want to plan some time for refactoring. However, if you’d like more, Martin Fowler, the author of Refactoring, has defined over 60 types of refactoring.

1. Refactor When Your Code is Hard to Read

Developers spend more time reading code than writing it. Previously, we defined the fully-loaded cost of wasting one minute per day over a year at ~$300 per developer. That can add up fast when it comes to reading, understanding, and identifying what needs to be changed in code a different developer wrote.

If code is difficult to read (i.e. spaghetti code) it becomes harder to find typos, structural issues, bugs, dependencies, and repetitions. Refactoring to increase readability increases efficiency across all tasks.

Software engineering managers or project managers should make use of style guides and document their use for successive team members. This extends to establishing a coding standard and making sure it is reinforced during code reviews. Documenting any changes to either provide the means for all future team members to quickly achieve a common standard across all of the company’s software projects – past, present and future.

2. Refactor for Code Bloat and Poor Performance

Whether it’s a web app, mobile app, or traditional software, end-users expect fast responses.
Code bloat slows software down. The slower software is, the less likely end-users will continue to use it if there are other options available. The overall impact for the software owner translates to fewer paying customers, placing poor software performance as on par with buggy software.

Bloat can be introduced in a variety of ways, by the programming language, compiler, or the programmer involved in producing the code. With Application Performance Management (APM) software, all manner of metrics can be tracked to identify slow components. Each bloated component can then be prioritized for refactoring according to impact.

3. Refactor When Your Software has Lots of Bugs

Funny story – from 2004 at Al Taqaddim, Iraq. Way back then, Iraq was supposed to be a “No Fly Zone.” In reality, it was swarming with billions of flies. Using a fly swatter to kill one fly would immediately attract 2-3 more within five seconds. Why? Pheromones. You can file that under Useless Trivia.

But it applies in debugging when you kill one software bug only to introduce 2-3 more! Test-Driven Development prompts you to write tests before the functional code to verify that you kill the bug. If any tests fail, you know where to look.

4. Repetitive Code

It’s worth prioritizing repetitive code for refactoring when you find it as you can help reduce software bloat (performance) and reading time. You’ll likely nab a few bugs in the process, too. If all instances of repeated code aren’t fixed it can create bugs and cause confusion as to which instance is correct. Each element of the program should be unique to keep changes on it from impacting others.

5. Refactor for Adding New Features and End-of-Life Software

Just as startups offering new ways of doing things emerge every year, many others go out of business or are acquired but discontinue service. Operating systems are regularly phased out, as shown in the table below. End-of-life software has its own dangers including security vulnerabilities, compliance issues (like GDPR), increased potential for software incompatibility and poor performance issues. Refactoring can help identify the affected code and components needing replaced.

While your project will take longer upfront, you reduce how much technical debt you’ll have later. Replacement options, operating systems, devices, and even third-party programs open up new functions that can be integrated into older software to keep it commercially competitive longer. You want to make sure all of the original code is working before introducing additional complexity with new functions.

6. Refactor as Critical Team-Members Transition

As team members tend to rotate regularly, it’s worth pairing them up with another team member to refactor the code they worked on most – before they leave. That’s not always possible, but this is another reason for maintaining and enforcing a coding standard. They likely know certain portions of the code best, especially if they wrote it. So, it’ll be easier for them to refactor while their replacement observes and learns the ropes. It’s entirely possible they inherited the code in piss-poor shape and had insufficient time to routinely clean up the code. There are other stories that we don’t need to get into, suffice that knowledge silos do form and this is one way to hand them over.

Code Refactoring Best Practices

The amount of time you can budget in for refactoring is never enough. To help you get the most out of the time you can find, take care to observe the following best practices for refactoring:

  • Make sure to have a backup of your code before doing anything.
  • If you’re using Git or another VCS, make sure you’re working on your local branch.
  • Verify that you have sufficient test coverage – aiming for 80% or better.
  • Check with your QA/Testing Teams for recommendations or support.
  • Create an incremental and methodical coding plan or checklist.
  • Have a plan to frequently test changes as you make them.
  • Stick to any coding standard or style guide being used, focus on “Good Enough” instead of “perfect code.”

Why is Refactoring Your Code Important?

It’s nice to be able to quantify things. A million lines of code printed out comes to 18,000 pages, or 14x as long as Leo Tolstoy’s “War and Peace.” It’d take a developer 4 months to read it. Keep this in mind, briefly – as we’ll come back to it. In the interim, however, there are plenty of qualitative benefits to code refactoring:

  • Makes it easier for all developers to read, understand, and analyze your code.
  • Educates and facilitates a better understanding of the code for developers.
  • Makes it easier to upgrade your software with new features.
    Improves software architecture to utilize fewer resources and increase security.
  • It can improve performance so it performs faster for end-users.
  • Helps find and fix bugs for more accurate results and a better end-user experience.
  • Makes it easier to upgrade your software with new features.
    Offsets code decay and helps pay down technical debt.

Why Do You Need to Refactor Code?

Code changes over time. The average software program has a lifespan of 6-8 years. Particularly large and complex programs with over one million lines of code can last 12-14 years. Aggravating the matter, the developers on a project change over time, too. For tech startups, turnover can exceed 25% in the first year. Industry-wide, software developers tend to change jobs every two years, on average. This brings us back to “War and Peace.” It’s entirely possible that 3-7 completely different development teams will be involved in maintaining a software program before it’s retired. Each team may not have to read through all one million lines of code. But, they’ll have to read through and understand significant portions of it before they can maintain or upgrade it. Each brings their own programming language fluency, newer skills, tools, techniques, and experience to the project.

Number of Operating Systems by Timeframe:

Timeframe iOS Android Windows
2001-2010 2 iOS 1-2 2 Android 1-2 4 2000, XP, Vista, Win 7
2011-2015 7 iOS 3-9 4 Android 3-6 2 Win 8 & 10
2016-2020 5 iOS 10-14 5 Android 7-11 NA
To this, we can add the ongoing evolution of operating systems, devices, technologies, and programs, while others stop receiving support and companies go out of business. Each new OS and device can prompt the addition of new features that could be integrated into older programs. The average lifespan of electronic devices is dwindling, ranging from 1.5 to 13 with a median of 4.5 years. Software often outlives the machines they were originally designed for. To remain commercially competitive, older software can be upgraded to make use of features supported by the newest devices. It’s also less expensive to update (or adapt) older software than it is (usually) to create new software from scratch.

About Gitential

Gitential is like “Google Analytics” for software development. Our automated analytics helps software engineers and software project managers track developer performance to measure efficiency, identify, and correct trends contributing to technical debt. If you have any questions about how Git analytics can help you, please let us know at gitential@gitential.com. We welcome you to sign up for a free trial, no credit card is needed.

Start your free trial now

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates.
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Subscribe to Our Newsletter

Don't miss our latest updates. All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Gitential.com Inc.

  • 874 Walker Rd Suite C., Dover, 19904, DE, USA
  • info@gitential.com
  • (650) 680 7697

Resources

Legal

Gitential.com Inc.

  • 874 Walker Rd Suite C., Dover, 19904, DE, USA
  • info@gitential.com
  • (650) 680 7697

Resources

Legal

Copyright © 2021 Gitential.com, Inc. All rights reserved
Twitter Facebook-f Youtube Linkedin