Refactoring is the process of "improving the design of existing code." Learn how to become a faster and more productive refactorer with Castalia.
This is the fourth and last installment of my series of articles discussing the results of our study into how Castalia helps developers become more productive. Over the last month, I've written about reducing work by reducing keystrokes, writing quality code faster with live error checking, and navigating through code faster and more accurately. This week, I will discuss one of Castalia's most productive and most useful features: Automated Refactoring.
It doesn't matter how good we are, we all write code that could be better. We often look at existing code and realize we could have used better class names, better separation of methods, better organization, etc.... This is what refactoring is about - changing existing code for the better.
The definitive work on the topic is Refactoring: Improving the Design of Existing Code by Martin Fowler. In this book, Fowler defines refactoring as "improving the design of code after it has been written." Refactorings are formal procedures for changing the design of existing code without altering the behavior of the code. (Incidentally, some of Castalia's refactorings admittedly aren't really refactorings, as they modify the behavior of the code).
The purpose of this article, however, is not to extol the virtues of refactoring or try to convince you that it's a good idea to begin with. I'll assume that you already understand why refactoring is necessary, or that you'll trust me when I say that it's a good thing. What I really want to do is talk about what we saw when we watched people refactoring code by hand, and refactoring code with Castalia.
When we observed developers at work, we noticed that many developers spent a considerable amount of time renaming things or reorganizing things. These fairly simple tasks could take days in large projects (imagine having to change every occurrence of TCustMan to TCustomerMan in 250,000 lines of code spread over 300 files).
Developers took a number of approaches to this. Most used Delphi's "Find in Files" feature to find every occurrence of the identifier in question and then opened each file and used Delphi's "Find/Replace" dialog to change the text. This seemed to be the most efficient way to do it, although we did observe another interesting approach: Some developers would just change the name of the declaration, and compile the project. When the compile would fail with an innumerable amount of "Undeclared Identifier" errors, they would go to each one and change the identifier. This is the method prescribed by Fowler.
Had the developer that we've been talking about known how to use Castalia's "Rename Class" refactoring to rename his class, things would have been very different. Using Castalia's automated "Rename Class" refactoring, the process takes less than one second. There isn't really a logical way to describe the improvement, since no one will believe me if I say that we can prove that Castalia can offer a productivity increase of 22,000% (1 second automated compared to taking 6 hours to do by hand), even though it is true.
Refactoring isn't just about renaming things, however. Another common example is the "Extract Method" refactoring, which we've all needed at one time or another. This is probably the most common refactoring performed by "manual" refactorings. We use this when one method has become somewhat monolithic and we know that parts of it should be broken into other methods. We cut and paste, move variables, add parameters, etc... until the code is designed better but the behavior hasn't changed. This refactoring is generally faster than renaming some globally-used object, but it has the interesting potential to introduce errors that weren't there before. Developers who learned to use Castalia's automated "Extract Method" refactoring found that they could get the method extraction done faster, do less work by hand, and drastically reduce the potential for introducing errors to almost zero.
How can you see the same productivity levels? Use the refactoring tools. Of course, that's easier said than done. Unlike structural highlighting or syntax checking, the refactoring tools do not jump out at you and say "use me!" Learning to recognize places where the refactorings can be applied takes a little experience, but knowing what's available can help a lot. Castalia's automated refactorings are:
Rename Class - Changes the name of a class, changing all references to the class to reflect the class' new name.
Move Class - Moves a class definition and all of its methods from one unit to another.
Rename Method - Changes the name of a procedure or function and all the references to the procedure or function.
Extract Method - Extracts a code segment into a separate procedure, replacing the original segment with an appropriately constructed call to the new procedure.
Rename Local Variable - Changes the name of a local variable and all references to the variable within a single method.
Inline Temporary Variable - When a variable is assigned the value of a simple statement, this refactoring removes the variable from the procedure and replaces all instances of the variable with the simple statement.
Split Temporary Variable - When a variable is assigned more than once, it is often wise to "split" the variable into two distinct variables. Split Temporary Variable automates this by adding a new variable to the procedure and making appropriate changes to split the original variable in two. (I wrote an article on this back in February).
Find References (Not a true refactoring) - Doesn't make any changes to code, but finds all references to an identifier in the project.
Surround With... (Not a true refactoring) - Surrounds a selected block of code with any of a number of standard constructs such as try..except..end, if then begin..end, etc.... This is not a true refactoring because it changes the behavior of the code, but we couldn't find a better place to put it.
Castalia's automated refactorings are real gem, and have made many developers and many development managers quite happy. The productivity gains from having nicely designed code are immeasurable. Taking advantage of Castalia's automated refactoring can help developers improve their code quickly and without tedium, allowing any code, no matter how poorly designed, to become great code.
This marks the end of our series on the Castalia usage study. Next week, it will be time for something completely different!