Guest columnist Ben Jordan, design manager at Altium describes the benefits of refactoring designs, the right way and presents a few tips to help prevent head-scratching
“Refactoring” is a word well known in software development circles, and it’s often one that invokes either boredom or spine shudders in those blessed few coders that have had to do a bit of it. Nevertheless it is an important concept – refactoring essentially means re-writing the insides of a module of code or at least a few functions in order to improve performance without compromising functionality or critical specifications.
It is often carried out by original authors who’ve got some “breathing space” after a release to go back and tidy up code that they know was rushed through development, or perhaps for extensibility reasons its dependencies may need to change.
If you consider what refactoring is at a basic conceptual level, you could say it’s a common activity across all design disciplines – in the mechanical world for example, an engineer may completely re-design a transmission on the inside without changing the housing, gear ratio, connections or base loading, perhaps redesigning for reduced noise and wear. You get the picture.
It’s also an activity often undertaken in the electronics department of many organisations – I am tempted to say all, though I can’t prove it. It’s the most fundamental form of design re-use – to take an existing design or portion thereof, make a copy of it, rename it, and start editing out the bits you don’t need and editing in the bits you do. You may have a more disciplined process than that, but this is very common practice in industry.
But there are flies in the ointment. Unless you are very careful and rigid in the way you make copies of design data for refactoring (or to begin a new revision of the product), you expose yourself to confusion about which version or copy of a document you are really working on. Everything can be fine until something you notice on the page pricks your conscience; that you may not be working on the file you first thought you were.
Another common problem is that when working with design documents that originated from a different author, you may not have a history of the changes they (or other authors) have made before you got a hold of those documents. What if you’re trying to do a modification for revision 3 when the source files you have obtained were only at revision 2, and you don’t necessarily have a way of knowing that unless the documents clearly contain that revision name or number – even then, you have to track down the right version.
Refactoring and design revisions need not be this uncertain or painful. With a little discipline and the right use of the right tools, you can be confident that you are doing the right edits to the right files. Altium Designer, for instance, has built-in refactoring tools that help you reuse and reapply design IP in an efficient, easy way.
If you’re interested in finding out what it’s all about and how it works check out the full version of this article at http://bit.ly/cuW8w3