In the coming year I’ll be starting a series on Refactoring. Refactoring is one of those programming ideas besides Design Patterns and Unit Testing which has made an order of magnitude improvement in my productivity. Although refactoring may not be a ‘Silver Bullet’ for your programming woes, it is a good tool to add to your mental toolbox.
Refactoring is a process of changing code to make it more understandable and structured without changing the code functionality or introducing additional bugs. Informally it is known as ‘cleaning up code’. Refactoring is based on the tenet that the written code is more important to the human reader than it is to the machine. Many programmers write code with the idea that once the program is complete and working the code will not be touched again. But this seldom happens. Features need to be added, bug issues need to be fixed. This may happen tomorrow or months from now; wherein you need to really remember what a particular function did. Comments in the code may be useful, but not much if the code written is not differentiable from the half eaten spaghetti bowl sitting beside.
Code refactoring is not to be confused with code optimization. Code optimization is a completely different ball game, where the goal is to run the program as fast as possible by using as few CPU cycles as you can. The focus during optimization is to speed up the program, if it impedes code understandability then so be it. On the contrary refactoring may at times make your program slower, albeit most of the times by a small factor. A sample code adapted from the wonderful book is shown below:
// Before refactoring
if($receiptDate < SUMMER_START || $receiptDate > SUMMER_END)
$charge = $quantity * $winter_rate + $winter_service_charge;
$charge = $quantity * $summer_rate;
/* After refactoring. The statements in the conditionals
have been refactored to functions. */
$charge = winterCharge($quantity);
$charge = summerCharge($quantity);
Many people refactor the code after the programming part is complete, many refactor as they go along. The important part is to test your code after refactoring. Unit tests are an indispensable part of this. Keep this maxim in mind – Always Test After Refactoring.
I’m planning to post one refactoring pattern every week or two. Although I could condense all the patterns in a lengthy post and be done with, I will resist that temptation. I want you to savour each pattern slowly so that you could remember and understand each of them like the back of your hand. There are more than fifty patterns catalogued by Fowler and others so it will help if we take it slowly. Most people after seeing the complete list of patterns become overwhelmed and confused and only remember a small percentage of them. Many patterns I’ll be posting will be self explanatory so I’ll do away with elaborate explanation. Refactoring is a habit and like all good programming habits it transcends the shifting landscape of technologies and languages.