Refactoring – An analysis of intent (Part I)

A mild warning. This article is more about idle philosophizing about refactoring in general than giving practical advice. I wouldn’t claim to be massively experienced with this topic. However, reading other people’s philosophizing might still be useful – if only to find things that you disagree vehemently with.

---

How should one refactor code? When should one refactor code?To answer this question, it is probably useful to consider the motivations behind refactoring in some depth.

Since refactoring as defined elsewhere specifically excludes the functioning of a program, the purpose of refactoring is to increase the reusability of code. (Where maintainability is included within reusability).

This means that refactoring is meant to make code easier to use in the future. Let’s think about how existing code is used.

It can be:

• Understood (e.g when trying to fix bugs, extend, interface to)
• Changed (e.g we might want to fix bugs, change default behaviour, add new behaviour or fork the code and use it for a completely new purpose)
• Interfaced to (i.e used) (e.g we can call methods in the code, or use its classes)
• Copied (e.g sections of the code might be removed and used elsewhere, or the rough outline might be used as the basis for someone elses program)
• Used in a way that I haven’t thought of yet.

When I find time and enthuism I’ll try to write about each of these uses in turn.