Code Refactoring...

It seems once every few months I need to go into "fixit" mode, especially everytime after taking a break for a few days. Today I've just finished fixing Keying Sets after they've been broken by batch-renaming madness again for the second time in as many months. Grrr!

This brings up an important point: "Code Refactoring" != "Code Redesign"



For many people, these two terms are pretty much synonymous with each other. Why? Because they carry the underlying ideal that "we're doing this to make things better". After all, that's what most development is about: improving our lot.

However, this is a fundamentally flawed view. There is quite a difference between the two.

Code Refactoring means making changes to the code that enhance its structure and style for the sake of the developers working on it. However, the key thing here is that it must not alter or break existing functionality from the user-perspective. It may clean up the code to allow for further developments to take place, ideally without breaking existing functionality in the process, but should never affect the functionality set.

Code Redesign is about making changes to the structure and style of the code too, but goes beyond being just for the sake of the developers working on it. Redesign implies change, as design refers to distillation of some set of ideas into a coherent whole, so redesigning means taking a second look at the ideas that we want to distill. This second look means that we look at the existing ideas (existing features), ideas that have come up since the original set of ideas was selected (feature requests), and ideas that we'd like to pursue in future (functionality we'd like to add). From these sets of ideas, we choose the ones we'd like to have in the new "design": this may be all of them, but equally or more likely is that we want to discard some of the old ones so that we can have room for some of the new ones which are inconsistent with the old ideas so that we have a coherent whole. Therefore, redesign does alter functionality available.

For that reason, if you're going about "refactoring" some code - renaming variables/settings/names for consistency, reformatting - then you really shouldn't be breaking functionality.

• If it isn't really area of code you're intimately familiar with, then it's probably a good time to compare the two versions of the code in action instead of just starting at them.
• If something isn't quite the same: you stuffed up!
• Otherwise, comparing it won't hurt, though just eyeballing it carefully is often enough in this case.