Council member John Ellis, FIAP has some thoughts on Code Optimisation and Re-Factoring
I’ve recently been working on adding new functionality and rules to a large ISA system. As part of these changes I was amending some Visual Basic code when I came across something like this:
IF p=q THEN
‘ Do X
‘ Do Y
‘ Do Z
END IF
Obviously the code does nothing and the IF block is just a waste of code and, more importantly, execution time.
Quite often (and I’m guilty of this, too) we see a block of code that is to be removed and comment it out. There’s nothing really wrong with that, but over the lifetime of a system it can lead to 50-60% of the code being removed this way. Quite apart from the potential for inefficient execution, it can leave the wood of real comments lost in the trees of ‘temporary’ edits.
I recommend either that code is simply removed (the source code control tools will keep an old copy anyway) or that comment-edits include a date. That way it’s easier for subsequent editors to notice (and remove) commented code if appropriate.
It does remind me, though, that developers sometimes need to step back and spend time really thinking about the code they change. It’s not just about removing extraneous code; sometimes it needs re-factoring.
For instance, a few years ago I was product-managing some code for an insurance quotation system. Rather than just looking at the code on screen, I printed it out so I could work on it while out of the office. Looking at the listing, I realised that one particular section of code seemed to be repeating itself, thus:
IF Insurer = 1
IF Thatched
Function1
Function2
Function3
END IF
END IF
IF Insurer = 2
IF Thatched
Function1
Function2
Function3
END IF
END IF
IF Insurer = 3
IF Thatched
Function1
Function2
Function3
IF LOCATION = “NORTH”
Function4
END IF
END IF
END IF
IF Insurer = 4
IF Thatched
Function1
Function2
Function3
END IF
END IF
…
…
There were about seventy insurers in total, some of them having five or six quotes each! Unsurprisingly, the system was taking around two minutes to execute them all. Having reviewed the code (twenty-plus pages of printout) I was able to re-factor it to:
IF Thatched
Function1
Function2
Function3
IF Insurer = 3
IF LOCATION = “NORTH”
Function4
END IF
END IF
END IF
Simple enough; but the code had been in place for around eight years and every new insurer or product just got a new block of code because that was the way it had always been done. The alteration removed twenty-odd pages of code and the execution time was reduced to 32 seconds. This obviously had a major system impact. Sometimes the re-factoring process can be dramatic as this, but the most noticeable thing from a developer’s point of view is that the code is easier to read, maintain and debug.
System managers and users are always pressing to have system changes implemented yesterday, but if we rush them in, we can end up with slow, difficult to maintain code that becomes more unwieldy over time. Gradually, the time spent making changes and debugging the code becomes uneconomic. The systems support developer ceases to be effective and a complete system or sub-system rewrite is necessary, taking months of analysis and development.
There are systems and methodologies to do this re-factoring, but sometimes the simplest and cheapest way is for developers just to stop and think about it occasionally, on the fly, so to speak.
You can contact John at john@74stonelane.co.uk
[Something you’d like to get off your chest? Email me (Robin Jones) at eo@iap.org.uk.]
-
VSJ – December 2008 – Sounding Board