Code Refactoring

As programmer Ward Cunnigham shares, “Skipping design is like borrowing money. Refactoring is like repaying principal. Slower development due to complexity is like paying interest.” At eSimplicity, we are not excited about skipping design, refactoring code, or paying interest. But we know that un-refactored code tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, too many responsibilities per method or class, duplicate code, and many other varieties of confusion and clutter. Every time we change code without refactoring it, rot worsens and spreads. Code rot frustrates us, costs us time, and unduly shortens the lifespan of useful systems. In an agile context, it can mean the difference between meeting or not meeting an iteration deadline.

The SIMPLE Experience

2 seconds worth of rinsing can become 10 minutes of aggressive scraping

A popular metaphor for refactoring is cleaning the kitchen as we cook. In any kitchen in which several complex meals are prepared per day for more than a handful of people, we typically find that cleaning and reorganizing occurs continuously. Someone is responsible for keeping the dishes, pots, kitchen itself, food, refrigerator clean and organized from moment to moment. Without this, continuous cooking would soon collapse. In your own household, you can see non-trivial effects from postponing even small amounts of dish refactoring: did you ever try to scrape the muck formed by dried Cocoa Crispies out of a bowl? A missed opportunity for 2 seconds worth of rinsing can become 10 minutes of aggressive scraping. eSimplicity’s team keeps our code hygiene clean by allocating time needed to refactor codes but caution the fact that perfection is the enemy of progress.

Precise and finite methods

It takes a while to learn to recognize refactoring opportunities and to implement refactorings properly. Refactoring is the opposite of fiddling endlessly with code; it is precise and finite. We like Martin Fowler’s definitive book on the subject, describing 72 specific “refactorings” by name (e.g., “Extract Method,” which extracts a block of code from one method, and creates a new method for it). Each refactoring converts a section of code (a block, a method, a class) from one of 22 well-understood “smelly” states to a more optimal state.

Smart tools help

To refactor code in eclipse or IDEA, eSimplicity selects the code we want to refactor, pull down the specific refactoring  needed from a menu, and the IDE does the remaining hard work. We are prompted appropriately by dialog boxes for new names for things that need naming, and for similar input. We then immediately rerun tests to ensure the change didn’t break anything. If anything was broken, we easily undo the refactoring and investigate.