Refactoring: An introduction for PHP programmers

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.

14 thoughts to “Refactoring: An introduction for PHP programmers”

  1. Another goal of refactoring is improving code re usability. When a particular piece of logic has to be repeated, it should probably be refactored into a method.

    One rule of thumb we keep at work is that if you have to copy-paste / yank a block of code, you’d better have a good reason for doing so instead of refactoring.

  2. The example could further be trimmed down with the ternary operator:

    $charge = notSummer($receiptDate) ? winterCharge($quantity) : summerCharge($quantity);

  3. @Ncloud: yes it could be trimmed down further. But refactoring doesn’t mean trimming down. Using the ternary operator instead of if/else is only a difference in style, while refactoring change the structure of the code.

  4. if(notSummer($receiptDate)) {
    $charge = charge_now(‘winterCharge’,$quantity);
    } else {
    $charge = charge_now(‘summerCharge’,$quantity);
    // refactoring cleaning your code up.OOP more better

  5. well refractoring is something like a combination of well understood ,self explaintory and well structured code

  6. Remember the rule for functions: Every function should only do _ONE_ thing. If you don’t do this already, try it, it’ll definitely change the way you code.

Leave a Reply

Your email address will not be published.