Code Of Practice

Code Of Practice

When to Refactor

Kootsookos says organizations should never refactor arbitrarily, but only when there is a real business reason to do so, although that reason might be as basic as the fact that the code has been written in such a cryptic way that new developers cannot understand it. And refactoring is best done during quiet periods; it is not a practice to undertake when deadlines are looming. "In general, refactoring requires a deeper understanding of the code and the way the code base is organized, and for that you need probably to be in a bit more contemplative frame of mind," Kootsookos says.

When to refactor can be a matter of personal preference, Watkins says. His own practice is to examine the code for each piece of functionality upon its completion to see whether it has been written cleanly. "If it doesn't express what I was trying to say cleanly," he says, "then I will apply refactoring at that point, to improve the communication process, to make it easier to read, and easier for someone else to come in and understand."

Watkins also routinely uses refactoring before adding new functionality to existing code, if it appears the code needs to be made more flexible to accommodate that functionality. "So I do it both before I start work, and afterwards," he says. "If you think of writing code as cooking, then refactoring would be like cleaning up the kitchen. You would do it beforehand if the kitchen was messy, and do it afterwards to make sure the kitchen is clean again."

Some organizations might do small refactorings every day, but also do larger refactorings that take several months to roll out for systems with serious problems. Such an approach often involves "a round trip to the development life cycle", Watkins says, which means going back to the whiteboard, documenting the new solution then putting it in place and finding out whether it works.

Safety First

But refactorings are primarily intended to be safe. The primary lesson is to be sure to proceed using small steps, Watkins says, no matter how large the refactoring itself is. You should also ensure each step is verified as it goes, because it can be very easy in large refactorings to head down the wrong path.

"If deadlines are looming it's usually not a good idea to refactor," Kootsookos says. "You have to have a reason. It's the old 'if it ain't broke, don't fix it'. You should refactor when you add functions, when you need to fix a bug, as you do a code review, or when code 'smells bad'," he says. You should avoid refactoring like the plague when it changes a published interface or when deadlines loom.

"One mistake teams often make is to attempt to do refactoring in big sections," Roodyn says. "This can be extremely painful for the developers, the managers and the customers as from the outside it appears that no work is being done."

Organizations should also position themselves to be ready to take advantage of any unexpected business benefits generated by the refactoring.

Scheer says one refactoring TurnAround Solutions did for a telco customer started essentially as a rehosting - moving a system off a mainframe-oriented environment onto a Unix-based server system - and has now become a project about delivering better service to customers. As the project migrated from a focus on improving performance and refactoring in terms of architecting technical architecture, to the services provided to customers, different stakeholders, including marketing, became involved.

This presents a challenge in itself that the IT group must manage, Scheer says, and the best way to do so is to ensure strong project governance and a solid alignment between IT and the business sponsors.

Scheer says the main difficulty with refactoring code is that the documentation is often not up to date, and business/technical knowledge about the inside of the system to be refactored has often "decayed". That means before you refactor you should undergo a period of upfront analysis, re-engineering of the design information and matching the system to the original requirements.

Then, as long as you make sure the refactoring will provide some business benefits, it can be one more valuable tool in the armoury used to ensure IT really does work to meet business needs.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about Aberdeen GroupAddison-WesleyADVENTAgile SoftwareBillionC2Carnegie Mellon University AustraliaCGIForbes MagazineHISIBM AustraliaJohn Wiley & Sons AustraliaMellonMicrosoftOracleSabre CorpSpeedSuncorp GroupSUNCORP-METWAYThoughtWorksTurnAround SolutionsUniversity of QueenslandUniversity of Queensland

Show Comments