Refactoring code is an essential activity when working with existing systems, as well as building new ones. Refactoring techniques allow us to safely transform code into designs that are perhaps better suited for future extension. The techniques used to refactor code range from very simple to quite complex and there is a strong emphasis to make small and safe changes to code so that we always have a buildable system.
Honestly, as I started to learn about refactoring and what it means I realized that the designs I come up with as I’m building a system don’t really matter because in practice it’s very straightforward to change the design as I’m building a system. After I’ve learned a series of techniques to help me do this, I found that is far more efficient to dive in and start building a system rather than trying to do a lot of upfront design.
What I’m doing upfront design I’m trying to visualize what the system will be like but I’m doing it in my head and on paper so is easy to fool myself. It’s also really difficult to see conceptually because we think in specifics, not conceptually. We think in terms of examples but we specify systems and talk about the design of systems as generalizations, so were constantly going back and forth between the general and the specific. Traditional specifications don’t give us a formal way of doing this whereas emergent design and test-first development does because we code from examples when doing test-first development.
The best time to visualize a system is when we’re building it out and I oftentimes do this through refactoring. Many IDE’s such as Eclipse and Visual Studio provide automated refactoring tools and this can save me a lot of time. Most of the basic refactoring operations have been automated and so they’re simple to use. There also mostly safe, which means that in many cases, we can use them on existing code even if that code is not under test.
My favorite refactoring is a safer factoring. It’s one of the things that I love about it. I can use this for refactoring on the most intractable and difficult to understand code without the fear of breaking anything. Plus, it’s my number one tool for understanding legacy code.
What is this amazing and magical refactoring? It’s Rename Method.
Having good, intention revealing names for methods is our first line of defense in documentation and helping readers understand what our code does. As I’m writing a method, I get clearer and clearer on what the method does and as I’m doing this I want to change the name of the method to reflect my new understanding. Rename Method lets me do this.
It’s a relatively simple refactoring with only eight steps, if you do it manually. I almost always use an automated refactoring tool to rename my methods so it’s simply a matter of highlight the method you want to rename, selecting the Refactor -> Rename menu option, type the new name and letting the tool do the rest.
I prefer long, intention revealing method names stated in the active voice. I don’t like abbreviations or acronyms. I like my names to be plain and simple. Methods should say what they do and that’s all.
I use the Rename Method refactoring more than perhaps any other refactoring and I’ll rename a method several times in the course of writing it as I get clearer and clearer on exactly what it does.
I also rename methods as I’m learning legacy code to give more clarity to the code. When I’m confronted with legacy code that I don’t understand then one of the ways I use to learn it is to rename methods if I feel their intention is unclear. Oftentimes, just the act of renaming key methods can help me gain a much better understanding of what’s going on in legacy code.
So, what’s in a name? Everything! Names let us give things meaning so make sure their meaning is clear, and if they aren’t use the Rename refactoring.
-
Pingback: My Second Favorite Refactoring – 1
-
Pingback: 私のお気に入りのリファクタリング - プログラマーのフロントライン
{2 Trackbacks }
Previous Post: « Surgery on Legacy Code
Next Post: My Second Favorite Refactoring »