Refactor As You Go

Extreme Programming (XP) has a nice principle called “Refactor as you go”. XP says that we should favor the simplest solution for a problem. I like the idea for a number of reasons, but most importantly for its cost-effective nature. Simpler design is faster to implement, results in less code (less bugs) and source code that is easier to read. “Designing simple” means designing for today’s problems; solutions designed for tomorrow often take ages to implement and output large amount of code to be tested.

This is not without price, however. Sometimes the design is proven too static for new requirements (see our last case) and often little attention is paid to modular design, reusability or consistency. This is where refactoring (improving code without changing its functionality) and “Refactor as you go” comes into the picture. The principle says that we should refactor to better code in small steps, as opposed to making big changes at once, because big refactorings are hard to do, open the door for new bugs and break at least one more XP discipline (“Small Releases”).

When programming methodologies and real life meet, you can feel the electricity in the air. Simple design serves short-term business goals very well (“get that new version shipped ASAP!”), but time-consuming and seemingly useless refactoring conflicts with them (“hey, why does it take two weeks to add a new report?”). It takes some self-discipline to take the Red Pill of refactoring, instead of the Blue Pill of the Commando Pattern. After all, it so much easier to get the job done quick, leaving tons of “TODO: Refactor” comments behind and it is so tempting to say that users care little about the software internals as long as it works. But then, points when you when you have to do a bigger refactoring always come.

Most of this week was spent with refactoring. Yes, it is a pretty big one, which means that there is seemingly no progress. ORF PowerLogs are still not fully integrated into ORF. The refactoring will take at least one more week, but even in mid-term, these changes will pay the price back, because the source code will be much easier to maintain. Not only PowerLog integration will be faster, but adding new tests to ORF or changing existing ones will take less time.

Stay tuned.

1 thought on “Refactor As You Go

  1. Pingback: Vamsoft Insider » …And… Action!

Leave a Reply

Your email address will not be published. Required fields are marked *

AlphaOmega Captcha Classica  –  Enter Security Code