What are the benefits of keeping your codebase up to date with mass refactoring tools?

Keeping your codebase up to date using mass refactoring tools offers several significant benefits:

  • Clean Code: Mass refactoring removes code smells (indications of poorly structured or inefficient code) and makes your codebase cleaner and easier to understand. Not only does this make the codebase easier to work with, but it also becomes easier for features to be extended or for code to be debugged.
  • Faster Coding: As refactoring simplifies and improves your code, it makes it easier to understand and work with (as mentioned above). This results in faster coding as you spend less time deciphering complex code or dealing with errors. It also enables you to reuse existing code components, saving time in writing new code from scratch.
  • Maintainable Code: With clean and improved code, developers can easily understand, update and fix it in the future. This ultimately simplifies the process of maintaining and extending the codebase over time.

How does e2y use mass refactoring tools to keep their codebase up to date?

When managing a long-term project, you may face several challenges in keeping your codebase clean and updated. These include dealing with updated framework versions, newer Java releases, evolving best practices, and the ongoing task of minimising technical debt.

In one of our recent projects, we found ourselves faced with one of these challenges. We wanted to update from Spring Boot 2.x to the new 3.x series, which included moving from Java 11 to Java 17. This was not a straightforward mission, as it required changes in our codebase to accommodate the new requirements of Spring Boot 3.x. To give more context, Spring Boot 3 migrated to Jakarta EE 10, meaning that some packages starting with javax, were moved to jakarta. Although these were small changes, they needed to be implemented across numerous sections of our codebase.

Fortunately, OpenRewrite came to our rescue. OpenRewrite is a mass refactoring tool that comes with the advantage of having many out-of-the-box “recipes” for updating to the latest version of well-known frameworks, migrating to newer Java releases, following coding best practices, and fixing style problems. And what’s better, it’s incredibly easy to use.

Since we were using Gradle for our project, we simply followed the instructions in the documentation and updated our Gradle build file with the following plugin configuration:

— START OF CODE
plugins {
id(“org.openrewrite.rewrite”) version(“6.1.22”)
}
rewrite {
activeRecipe(“org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_0”)
}
repositories {
mavenCentral()
}
dependencies {
rewrite(“org.openrewrite.recipe:rewrite-spring:5.0.7”)
}
— END OF CODE

As you can see we have only applied one recipe “Update to Spring Boot 3.0”, which you can view in this documentation, Migrate to Spring Boot 3.0, includes the migration to Jakarta EE 9 and the migration to Java 17.

After executing the recipe all the changes were successfully applied, and our unit and integration tests were running with no issues. So now, not only do we have our project running on Spring Boot 3.0 and Java 17, but we also get some other goodies like a more idiomatic usage of Java 17. For example, our code start used String.formatted(Object…) instead of String.format(String, Object…):

– Old: String.format(”Expected field ‘%s’ has not been found, item.getCode());

– New: Expected field ‘%s’ has not been found”.formatted(item.getCode());

How frequently should you perform this?

Mass refactoring is especially useful when you are migrating to new versions or when you want to do the same refactor in many places of your project, which you can do by writing your custom OpenRewrite transformations: Authoring Recipes. However, in the case of keeping up to date your code base, is better to regularly update your dependencies and take a look at the available recipe list (Modernize) to ensure that. Think of a “Dependabot” approach but not only upgrading the dependencies but also your code.

Is the process safe to undertake?

OpenRewrite isn’t just a basic tool for finding and replacing specific text in code. Instead, it’s a more advanced tool that focuses on making meaningful changes to the code’s structure and logic, in a way that preserves the original structure using a special tree-like structure called Lossless Semantic Tree. This ensures that the code changes not only look correct but also maintain the proper structure and instructions needed for the code to be compiled and run without errors.

Nonetheless, you need a good unit and integration test suite to ensure that those changes don’t introduce any regression bugs.

Does this work with SAP Commerce?

Since SAP Commerce doesn’t use Gradle or Maven you can’t use OpenRewrite directly (SAP Commerce uses Gradle for some things but the build itself is handled by Ant). However, with a bit of scripting, you can create a simple build file with all your project directories and the essential classpath information for your extensions, since this is all you need to apply an OpenRewrite recipe.

Image by Freepik