Understand code smells and how refactoring can help

One thing that most app developers and testers eventually encounter, especially when working with complex apps or on large teams, is the code smells. These are tangible, observable indications that there is something wrong with an application’s underlying code that could eventually lead to serious failures and kill an application’s performance.

Here are typical examples of code smells:

  • duplicate code
  • dead code
  • long methods
  • long list of parameters
  • comments
  • useless primitive variables
  • data heap

Particularly “smelly” code could be inefficient, non-performing, complex, and difficult to modify and maintain. Although code smells don’t always indicate a particularly serious problem, tracking them often leads to discovering reduced code quality, exhausting application resources, or even uncovering critical security vulnerabilities embedded in the code of the application. the app. At a minimum, this forces teams to do extensive testing on the code – and often reveals some critical areas of the code that need patching work.

Let’s explore how software teams can identify code smells and use them to maintain a higher degree of code cleanliness. We also examine how techniques such as code refactoring and regression testing plays a vital role in dealing with code smells and fixing the underlying issues.

What Causes Code Smells

Simply put, code smells are the result of poor or misguided programming. These errors in the application code can often be directly attributed to errors made by the application programmer during the coding process. Typically, code smells come from a failure to write code to the necessary standards. In other cases, it means that the documentation required to clearly define project development standards and expectations was incomplete, inaccurate or non-existent.

Many situations can cause code smells, such as inappropriate dependencies between modules, incorrect assignment of methods to classes, or unnecessary duplication of code segments. Particularly smelly code can eventually cause serious performance issues and make critical applications difficult to maintain.

Keep in mind, however, that a code smell isn’t an actual bug – it’s likely that the code still compiles and works as expected. Code smells are simply indications of potential violations of code discipline and design principles. That said, it’s possible for the source of a code smell to cause cascading issues and failures over time. It’s also a good indicator that a code refactoring effort is in order.

Eliminate Code Smells with Refactoring

Code refactoring is one of the most effective ways to eliminate code odors and maintain good code hygiene. Refactoring is a process of restructuring that attempts to make code cleaner, more concise, and more efficient without altering its core functionality. Regular refactoring helps ensure that code follows a team’s guidelines and aligns with a defined architecture.

The best time to refactor code is before adding updates or new features to an application, as it is recommended to clean up existing code before programmers add new code. Another good time to refactor code is after a team has deployed the code to production. After all, developers would have more time than usual to clean up code before being assigned a new task or project.

A caveat to refactoring is that teams should ensure that test coverage is complete before refactoring an application’s code. Otherwise, the refactoring process may simply restructure broken pieces of the application for no gain. Regular refactoring is not a good idea in the face of tight release schedules – the required testing takes a lot of time and can prevent the team from releasing the app on time.

Many tool options are available to automate the code refactoring process, including SonarQube, Visual Studio IntelliCode, Rider, and Eclipse IDE. Many of these tools allow programmers to perform code restructuring alongside the actual development process, which can help teams accelerate release cadences when needed.

Refactoring Techniques for Code Smells

Refactoring encompasses a number of specific code hygiene practices. However, when it comes to eliminating code smells, there are three particularly effective techniques: one that focuses on methods, another that focuses on method calls, and a third that focuses on classes. .

Dialing methods

The first technique, composition, aims to eliminate redundant methods. There are two distinct ways for developers:

  1. The code is broken down into smaller code blocks. The fragmented code is then isolated, extracted, and placed in a separate method.
  2. Broken or useless methods are identified, as well as calls to these methods. The method calls are replaced with the actual method code and the original method is removed.

Simplify method calls

The next technique is to simplify method calls that over time have buried themselves in vast amounts of code that are daunting to work with. Programmers have several ways to simplify method calls, including the following:

  • add or remove certain parameters;
  • rename methods with ambiguous names;
  • separate requests from the modification component;
  • parameterize methods and introduce parameter objects;
  • remove methods that assign certain values ​​to objects; and
  • replace the parameter with explicit methods or calls.

Refactoring by abstraction

Finally, refactoring by abstraction comes into play when large chunks of code contain duplications or redundancies. There are two techniques that make up this approach, both of which focus on class inheritance:

  1. Go back up. The code behind the methods shared by an entire group of subclasses is extracted into a superclass.
  2. To lower. Method code that lives in a superclass but is only used by a few of the subclasses is pushed to those respective subclasses.

Consider the following code snippet that demonstrates two classes: file recorder and DbLoggerComment. As the names suggest, file recorder is responsible for logging data to a file, and DbLoggerComment saves the data in a database.

An example of code redundancy

the IsLogMessageValidIsLogMessageValid the method returns true if the log message is valid and false if it’s not the case. In this case, a log message is not considered valid if it contains a null or empty string. Similarly, the log message is considered invalid if it contains sensitive data, such as a social security or credit card number.

Unfortunately, this approach is a bit redundant. Programmers would need to write the same logic twice – one for each of the two classes – to check if the log messages are valid. A better way is to refactor these two classes and create an abstract class. In the code segment below, note how the IsLogMessageValidIsLogMessageValid The method has been moved to an abstract class, which helps alleviate potential code redundancy.

Refactor by abstraction
An example of refactoring by abstraction

The role of testers in refactoring

It is essential to ensure that the code is testable before the refactoring begins. This includes, but is not limited to, unit testing, regression testing, and integration testing. To this end, it helps to involve the test team throughout the refactoring process, as tests can fail once development teams start modifying code. Regression testing is particularly important in refactoring, as it ensures that the functionality of the application remains intact.

Refactoring should be a recurring activity and it is essential that it is a collaborative effort. By regularly performing code hygiene tasks together, software teams can create centralized strategies to identify code smells and learn from mistakes. It is also useful for testers to learn more about the code restructuring process, as it can help them improve existing test cases and procedures. It can even help them write better test automation code and reduce manual maintenance tasks.

Comments are closed.