You Are Very Likely To Have Done It Before
Even though my Microsoft Word 2003 has just underlined it with the red squiggle, the word “refactoring” is quite well-known nowadays. Even if you have never programmed in Smalltalk (the concept was born in the Smalltalk world), you might have heard or read it here or there – well, several lines above at the very least. I say 'at the very least' because refactoring is gaining popularity in the .NET world – to the point where Microsoft has decided to introduce it in Visual C# 2005.
However, I guess there are many developers who believe it is something they have never tried to do and if they have to, there’s yet another new concept to learn. Well, I have some good news for them: not really.
As unbelievable as it may sound, all of you are very likely to have refactored your code a number of times in your programmer’s career. Surprised? OK, have you ever done one of the following:
Devised a more appropriate name for a method or a parameter and then searched and replaced the old name everywhere in the code?
Added a new parameter to a method of a class and then edited all the places in the code where the method is called and passed in a value for that new parameter?
Taken a piece of code and moved it to a separate method to make it reusable or to just make the code more readable?
Even if you have never done exactly these things, I think you will have got the idea anyway. I am talking about the sort of changes to code that neither add new features nor fix defects, but rather facilitate both of the above. Such changes can be anything between local and profound, but usually can be performed (and are performed from time to time) by any skilled software developer.
The Simple Secret of Popularity
So, if the subject matter is something almost every programmer has done before, what makes it so popular nowadays? Didn’t software developers want to improve their code in the past? No, we all are pretty sure they did and actually made their code better when the need arose. However, what they lacked was a systematic approach and means of sharing the code reengineering techniques.
If you think about it, all this code reengineering can be boiled down to a fixed number of modifications, each serving a specific purpose. Let’s take adding a new parameter as an example. You can easily guess the purpose of this particular modification: to pass additional information the method requires from the caller. The same is true for renaming a method - the purpose is to make the name more descriptive. Moreover, one can write a detailed, step-by-step instruction for either of these modifications (as well as for any other of that sort). As an exercise, you can try to come up with the purpose and possibly the instruction for the second example above, moving a piece of code to a separate method.
Now, what if we were to take the purpose, the description of every known modification and the relevant step-by-step instruction and put them all together in some kind of a cookbook? Well, that’s practically what Martin Fowler, one of the founding fathers, did for his famous book, the lion’s share of which is the catalogue of the most widely used code improvement techniques. A number of benefits ensued from publishing the catalogue:
Unified, well-known names for each of the techniques that facilitate communication and knowledge transfer.
Succinct but precise descriptions of applicability enabling you to check whether a particular code modification is appropriate for your needs.
The large variety of techniques suggests improvements to those parts of your code that you would never think could or should be improved.
And that’s what, I believe, allowed refactoring to gain so much popularity among software developers – an established framework for code reengineering offering off-the-shelf field-tested and reliable recipes that save time and effort and greatly reduce the number of potential problems.
Visual Basic Is Invited!
Some of you might have found that most refactoring examples are in Java, C++ or in C#. And this is for a good reason. All these languages are more or less close to each other, and there’s a culture of pure object-oriented programming, especially in the Java community. The tools are also a major contributing factor. Quite a number of solutions for Java developers have been around for a while, and there is also noticeable support for C# with major players on the market - Microsoft has introduced code reengineering in Visual C# 2005.
VB .NET is, however, a different story. Its syntax is very different, and, according to Tom Archer, many VB programmers have difficulties understanding C# or C++ code. Nevertheless, VB .NET is no less suitable for the code improvement! Moreover, even in VB6 (or VB.OLD, as some people tend to name it), you can employ many of these techniques, probably even more than you can currently think of. Still, if you come from the VB6 background, you might be more comfortable if you start from the techniques that do not require previous object-oriented experience, as these are the ones you are most likely to apply first. And as your learning progresses, you will discover new depths of the object-oriented power of the next generation of the Visual Basic language.
Speaking of tools that would enable code reengineering in VB .NET, take a look at SubMain’s CodeItOnce. In the next part of the series, I am going to give you several examples of improving existing VB .NET code with the help of this tool. You can think of it as a small hands-on code reengineering lab which demonstrates the structured approach to making certain well-known modifications such as adding a new parameter.