beawolf - Fotolia
Code refactoring tools are plentiful, no matter which technology you are using. Whether it's Java, PHP, .NET or anything else, tools exist to make the laborious process of refactoring code easier and safe. In fact, so many code refactoring tools are available that it is difficult to choose among them.
Here we will discuss the features to look for when choosing a tool and explain how each one can affect the refactoring process.
Method and variable renaming
Renaming methods and variables is the most common thing I do when refactoring code. What was obvious to the developer before me (thus, a long descriptive name wasn't used) is not so obvious to someone new to the code. As I scan through a new codebase to get acquainted with it, I will rename variables and methods as I go to more completely identify what they do.
Virtually all code refactoring tools will do this, but a feature to look for is a tool that will also change the comments. Often comments will refer to variables by name and if you rename the variables, those comments no longer make sense.
Generate interface after renaming
After the renaming feature, generating an interface is what I use the most. Updating older code often means introducing interfaces to existing classes in order to introduce Inversion of control. Generating interfaces by hand is not difficult, but retyping all the property and method signatures you want to expose is tedious and error prone.
Extracting a method
Taking a large method and breaking it up into testable pieces is a common practice when refactoring for unit testing. Having a feature where you can highlight a set of lines and extract those to a separate method, complete with appropriate parameters, can save a lot of time.
When using this refactoring, be careful to examine the generated code. I've not found any refactoring tool that does this well, although what is produced at least gets me started. To get the best results, be careful with the lines you highlight to extract and make sure you include any local variables in that range. Even if a variable is local, if the declaration is not included in the highlighted section it will be passed in as a parameter. Luckily, the resulting method is used only in one place so refactoring the parameters by hand is not difficult.
Extract a parent class
When working with legacy code, I rarely find the idea of a base class implemented. I like to put as much logic in a base class as possible and inherit into child classes to make processing easier, and to help when working with Generic methods and classes.
Having a refactoring feature available to extract a parent class (or super class) is helpful when defining these base classes. Select the properties and methods you want in the base and hit the button to create the new class and make the current one descend from it. Unfortunately, I've never found a code refactoring tool that will also scan through other classes to find those that should be siblings. When artificial intelligence is a bit more intelligent, maybe we'll see this feature as well.
Change method signature
Manipulating method signatures can be error prone, especially for methods where all the parameters are of the same time. What if you have a method that takes two strings, but the order of the parameters doesn't make sense to you for some reason? Without automatic method signature manipulation, changing the order of those parameters is a risk because if you forget to change the order in one of the method calls, the compiler won't find that error.
Extract DTO from method signature
I'm a fan of directory toolkit outputs (DTOs) for passing data among methods that need more than one or two parameters. Having a long parameter list is difficult to read and hides the relationship between different methods -- two methods having the same long signature is harder to see than two methods that accept the same DTO as a parameter. It is also possible to add some validation logic to the DTO to ensure all necessary data is available (I know this stretches the definition of DTO, but let's ignore that for now).
Having a refactoring feature that extracts the DTO from the signature should also refactor all the calling code to use that DTO. That could potentially be a lot of code. When used, this feature can save a lot of time.
Move to a resource file
My last suggestion is something I don't use often, but when I need it, it saves a lot of time. When adding I18N support to an existing application, all those strings that have been hard-coded in the app need to be moved to a resource file. This is painstaking, tedious, error prone work that quickly makes me want to take a break (read: do anything but this task). If you are adding multiple language support to any application, this feature alone is worth whatever you have to pay for the code refactoring tool.
Dig Deeper on Application development and design
Related Q&A from Brad Irby
Can microservices help modernize legacy applications? An expert lists ways microservices help developers break the monolith into functional services. Continue Reading
When designing an application, developers must decide how to implement data persistence. Brad Irby explains which data persistence pattern to ... Continue Reading
How do refactoring problems come about, and is there a way to predict them? Contributor Brad Irby has the answers. Continue Reading