Refactoring – An analysis of intent (Part II – Understanding)

Summary: We can roughly taxonomize the type of understanding needed from source code by considering:

• Whether the reader is trying to understand what code does or how it does it.
• Whether the reader wants a vague or exact understanding.
• What fraction of the code is the reader trying to understand. Are they just trying to understand a local area or are the trying to understand the program globally as a whole?

For each type of understanding, some types of refactoring may make understanding easier, whilst others may make it harder. This is particularly relevant for vague understanding and local understanding.

Regardless of what the reader is trying to understand, some things just make reading code easier. Writing code that is the same as – or analogous to – code that others have already written makes understanding a lot easier. Making code consistent allows the reader to remember a limited set of rules rather than actual details. Doing what people expect means they won’t be suprised and confused. With this is mind, we see that using patterns and idioms makes code a lot easier to read – provided that the reader knows the idioms and patterns. Some refactoring may be good at doing this – other refactoring might be bad…

---

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.