Refactor to Learn an Existing System

One of the best opportunities to refactor code is when you’re starting to get to know it. This not only helps improve the code but it also improves your understanding of the code and helps everyone else who touches the code in the future.

There are many kinds of refactorings that one can do to existing code that is not under test which are safe and helpful for embedding understanding code. When we have a bunch of existing code that’s not under test it can be dangerous to make major changes to it but these safer refactorings allow us to make small, safe, and incremental changes to code in ways that can also help us learn a system.

One of my very favorite refactorings to help me learn a system is Rename. Rename is a really simple refactoring but one I use all the time. It’s not uncommon to find methods that have misleading names and when I come across this I often use the automated Rename Method refactoring in my IDE to change the name to one makes more sense. I find that just this one refactoring, Renaming Methods, can vastly improve the clarity of a system and that helps me learn it much faster.

Since the Rename refactoring is a nondestructive refactoring and one that many IDE’s have automated, it is very safe to use, even on software that’s not under test. However, if I’m very concerned about the safety of a method and I may have callers that are external to my code then one thing I can do is leave the existing method alone and simply wrap it in another method of my own with the name of my choosing. That way I can change all of my internal callers to use the wrapping method with the new name so that it’s clearer on what they’re actually doing and external callers are still able to call the original method with its original name directly.

I and others have written a lot about what makes a good name for a method. I won’t go into that now except to say in a nutshell that the goal of the name of a method should clearly state what it does. Think of a method name as a promise to provide some kind of behavior or service to its callers. When a behavior is given the right name then much of the system starts to make sense that didn’t before.

Renaming methods can help bring clarity to legacy code and is a really excellent way to improve my knowledge of that code while making it just a little bit better for the next person who comes along and needs to work with it. Because Rename is among the safest of all the refactorings, I feel that I can use it in almost any situation and this helps me embed knowledge into an existing system, improving the system, as well as improving my understanding of what the system does.

Note: This blog post is based on one of the “Seven Strategies…” sections in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.


To view or add a comment, sign in

More articles by David Scott Bernstein

  • Green Tests and Red Tests

    In practice, I found that there are times that I want a bit more test coverage than I get from just doing test-first…

  • Radiators and Silos

    In the old days of corporate America, the way you got ahead was through hard work and perseverance. You strove to…

    2 Comments
  • Makers and Menders

    I’ve been getting back into some research interests of mine that require data acquisition from a variety of sensors so…

  • Core Developer Practices

    Every field of engineering has a core set of practices that they follow and software engineering is no different. But…

    1 Comment
  • Still XP After All These Years

    Are you humming in your head Paul Simon’s “Still Crazy After All These Years”? I am. And it does seem crazy.

  • The Importance of Continuous Integration

    Perhaps the most important yet easiest to implement of all the software development practices in Agile is continuous…

  • The Importance of Technical Practices (Again)

    Software development has undergone many revolutions over the last few decades. The way we build software today is…

  • Summary of Seven Strategies Series

    I finished my “Seven Strategies” series of 72 blog posts with seven strategies for implementing each of the nine…

    1 Comment
  • Refactor to Learn What Not to Do

    One of the things that I was not expecting when I started refactoring other people’s code was that I started to see…

    4 Comments
  • Refactor to Clean Up Before Moving On

    Of course, the best time to refactor code is while it’s fresh in your mind, right after having worked with it. Once I…

Others also viewed

Explore content categories