Refactor reasons

Below are reasons why someone might refactor. Refactoring here means changing the code while the application (or library) behavior remains the same. If the code does change the behavior, I prefer the term "rework," for example, when introducing caching or replacing a library. And if it fixes something like a security concern, you're adding value to the application by changing behavior. I recommend not calling that refactoring since that wouldn't inform the customer. It's better to tell a paying customer why the "additional work" was needed.

Another way to think of it is that when refactoring, the only ones benefitting are the developers. I'm not saying you should avoid them, but if you decide to refactor, take a step back and look at what you are trying to accomplish. That way, you have a clear goal. And when a customer asks, you can explain why the refactor is essential.

The list

Performance

This is one I hear often from developers but when I look at the result the increase in performance is rarely there. Sometimes it's the result of some other work (like replacing the database).

Examples:

• Replacing an algorithm
• Reorganizing data/memory allocation (by aligning it to the 4 bytes)

Organization

In my opinion this one is undervalued. Code that is poorly organized means that the work done by developers can't be organized. Worse, it's often an indication that the team is unorganized.

The problem is that most often someone tries to fix it without communincating or agreeing on a direction. Which makes the code more disorganized for others.

Examples:

• Rename or move methods, classes, files, and on to meet some level of standardization.
• Reducing code duplication so fewer lines of code are in the codebase.
• Duplicating code and specializing it so that the multiple specialized versions are less code than the single generic version

Readability

Frankly hardly worth mentioning. It's one that I do all the time when I work. The bigger question is always why and how did the code become unreadable? And what level of reading skill can we ask from our team-members?

Examples:

• Renaming methods, classes, files, and so on so that it's more readable
• Formatting the code so that it's easier to read

Metrics

The worst excuse unless metrics serve a direct purpose. Then again, I'm not a fan of code-quality tools (such as SonarQube) since they often provide poor advice for junior and even medior developers.

Examples:

• Changing primarily stable code to get better numbers from a QA tool.

Consistency

Useful, but only if it becomes a problem. One should take in account that this is basically the tabs vs spaces all over again.

Examples:

• Using `rgb(0,0,0)` everywhere instead of `black` in CSS.

Preparing for the future

"We might need it" implies no current need. And although some preparation for the future is advisable, one should always optimize for changing the code. By overpreparing, we often lock ourselves in a direction that might be hard to change in the future. Better to not prepare and always quickly change than always to prepare and be unable to change the code.

Examples:

• Changing code for something that might happen by adding possibilities to extend it.

Testability

Frankly, this is another one that can be part of the regular work unless there is some highly problematic design. In such a case, it would be better to consider it a project. The only exception is changing the code to improve testability when the only goal is testing. Adding tests afterward often results in being unable to change the code.

Examples:

• Changing code so that it's easier to test.