(Original creator: eknochs)

This blog is an extension to my earlier blog on Removing Dead Code.  One of the benefits of removing dead code is to make future code maintenance easier, and therefore cheaper.  Recently I read a blog which reminded me of the proper definition of refactoring, and I realized that refactoring is a logical next step after removing dead code.  One problem is knowing what it costs to do it. Let’s start with the original definition of refactoring, as defined by Martin Fowler and Kent Beck: A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs. So the users will visually see no benefit from this kind of work.  Without a specific project mandate to improve the code, what developer will risk breaking a working module just to make it easier to understand? I think that refactoring will mostly get used when it’s piggybacked on to other tasks, which could be from one of these categories:

Choosing the scope of code for refactoring shouldn’t be too difficult.  Operations, included proc modules, validation triggers, or whole components are all candidates, based on their modularity.  This just means that they have a well-defined interface, use case, or unit test script.  Just be sure to complete the refactoring completely, before starting on any business rule related changes.  You should view refactoring and other changes as separate but serially executed tasks.  This will make the refactoring effort less error prone, and more measurable. So do look out for opportunities to refactor modules of code.  You know that it will be faster than refactoring is in other languages.  Uniface’s high productivity will help during refactoring as much as much as it did during the original development.