September 22, 2020

Refactoring in Software Development

When it comes to the software development life cycle, Refactoring is a common term. In this blog article we talk about refactoring in software development.

Refactoring is a term used by software developers to describe the process where they replace components, code, the wiring, or structure of a software application without changing the actual functionality or user experience.

It is very similar to going to an auto-shop and saying you want to drive your car faster. And the technician tells you we can do that but we’ll need to change your “R” rated tires for a “Z” rated tire if you want to go that fast. You say, Ok do it. They change out the tires, and now your car has some improvements to it, you can now go faster and have better control on the turns, since they are much better tires. But the basic function of the car hasn’t changed – you still use a steering wheel, brake pedal, accelerator, gear selector, the windows and doors still operate the same way, etc.

Likewise, you might want your new tires to last 75,000 miles, instead of 40,000 miles. Thus, reducing your maintenance costs of your car.

To expand upon this analogy further, sometimes parts simply get too old and are no longer maintained or supported by the manufacturer, so if they break your car won’t run. So, sometimes we use refactoring to replace a part that is no longer supported or being manufactured, often with a better more improved part, to prevent the car from breaking down.

Potential Benefits for Refactoring

While every refactoring project is different, here are the common benefits and reasons why a software development team may want to refactor an application:

  • Reduce Complexity.
  • Improve Performance.
  • Improve Maintainability.
  • Simplify the Internal Architecture and Design.
  • Add Improvements for Future Growth.
  • Replace components that are no longer Supported.
  • Replace components or code that have newly discovered Security Flaws.

Typical Refactoring Strategy

Because one is changing parts or code within an application, you want to minimize the amount of change that you are making at any one time, to reduce the risk of a significant failure.

This is often called micro-refactoring, where a tiny change or a single component is swapped out for another.  This reduces the overall risk, as well as the amount of time (and cost) required for testing the new component or code.

Using our auto-mechanic analogy, when you change your tires you will probably get them aligned and balanced, which is normal. But you probably don’t want to swap out the drivetrain and engine at the same time as this would take a lot more time and introduce more risk. Because, if there is a problem then it will take a lot longer to determine where the problem is. Since so many components were changed at the same time.

In addition, if something does go wrong, a small change is easier to reverse (back out), than if you make multiple larger changes.

Reasons for Refactoring

Typically, the reasons to start Refactoring an application will come from several sources:

  • Customer Complaints about the Application.
  • Internal User Complaints:
  • Slow performance of the user interface.
  • Reports taking too long to run.
  • Things the Software Team knows needs to be fixed:
  • Old code that doesn’t do anything anymore.
  • Code that should be split into smaller pieces.
  • Short cuts that were taken initially that need to be fixed.
  • Code that needs to be optimized.
  • Memory Leaks:
  • This is where a piece of code uses up some memory to function, but then when it is finished doesn’t give it all back.
  • So, overtime more and more is allocated to this process until it causes problems for the entire application.
  • Newly discovered Security Vulnerabilities.
  • Components that are no longer supported by a 3rd Party, so if they break, you have no one to turn to.

Incurring Technical Debt

When a software development team doesn’t perform refactoring on a regular basis, they incur what is known as technical debt. These are things that the team knows need to be fixed or changed, but keep getting put off due to other business priorities. The problem with this is that it can easily cause longer term issues and become more costly and time consuming to fix.

Using our auto-mechanic analogy, a typical gasoline engine in a car should have its oil and oil filter changed once every 5,000 miles or so. But with modern engines, if you go over that the engine will still run fine… for a while. But the longer you go, the higher your risk of the engine seizing up and not working. So, now you not only have to replace the oil, but the entire engine.

This is why we should think of continual refactoring to be a software maintenance activity on the application.  It is something that we have to do, in order to keep the machine running at optimal performance.

ArkusNexus Engineer at work

Importance of Testing

When a software development team is refactoring a portion of the code or replacing a component, it becomes critical that they test the new code or component in an environment that closely mimics the actual production application.

Typically, the team will conduct:

  • Automated Unit Test – on the new component or code to ensure that it works, then...
  • An Automated Regression Test – ensuring that the new component or code works as expected with the parts of the Application that it affects, and finally...
  • A “Smoke Test” – once the new code or component is deployed to production.
  • This term comes from the 1960’s, because it is a quick test that should take as long as a “Smoke Break”, so it only focuses on the most critical parts of the application.

Other Business Considerations

When looking at which applications or integrations (component and code) to prioritize first in refactoring, we also need to consider:

  • Business Criticality of the Application.
  • An airline ticketing system is very critical, because if it goes down, the business halts.
  • A cafeteria ordering system for your employees lunchroom, not so much.
  • Data and Information Security – if we have a known or suspected security flaw, and we get hacked, how does it impact our:
  • Customers.
  • Revenue.
  • Company brand image.
  • Regulatory fines we may have to pay.
  • Technology Components or Coding Languages that are no longer supported.
  • This directly impacts IT’s ability to support, troubleshoot, and administer the application.
  • Depending upon the criticality of the application, this may be extremely important, or much lower risk.

Just remember sometimes what we are Refactoring is not an entire Application, but rather the custom code that often Integrates two or more commercial off the shelf applications together.

In Summary

During the life span of any custom application or Integration, you will frequently have to Refactor the code or components. So, this needs to be planned for and funded accordingly.

The single biggest factor is what is the criticality or importance of this application (or Integration) to the overall business and its operations.  The more important it is, the more efforts are needed to ensure that it is functioning as efficiently, effectively, is maintainable, and is operating with a high level of security as possible.

We hope that this has been beneficial and useful to you, remember to contact ArkusNexus for any of your software development needs.

Case Study from Arkusnexus
David Annis
David is a VP and Agile Coach within ArkusNexus, having served in multiple CIO, VP of Software Development roles. He assists our Sales, Marketing, and Operations Teams on critical initiatives.
RSS feed
Subscribe to our feed
Back to More ContentMore From this Author

3065 Beyer Blvd B-2
San Diego CA 92154 - 349

mind hub tijuana