Refactoring Workflow

refactoring-workflowRefactoring is a very useful concept and a must have for development teams. It is used together with Test Driven Development. It help keeps the code clean, not only during creation, but also during further development.

Refactoring basically means a rewrite of the code to make it better. Bad code can result from bad developer or good developer on a bad day or time constraint requirement.

The end result of refactoring is always cleaner code. Meaning, the code is simple and flexible. Simple to understand and can be easily extended.

There are multiple type of refactoring, depending on their workflow. Martin Fowler described them best in his infodeck “Workflows of Refactoring“.

TDD Refactoring

Refactoring in TDD (Test Driven Development) begins with Red Green Cycle and Refactor as another step in the Cycle. A Red step means that the first code created is the unit testing code, which will always fail, hence the Red step. Then code are added to get the unit testing code to pass, thus, the Green step. Only after the Green step, does a developer add Refactoring.

Opportunistic Refactoring

This type of refactoring is, as the name implies, rises on occasion. Most likely the developer is working on something else and found the current code to be bad or incomprehensible. He then decided to refactor those codes.

Martin Fowler divide the opportunistic refactoring in two:

Litter-Pickup Refactoring

This workflow happens when a developer is checking a codebase and found it to be substandard. He/she then uses the opportunity to improve the code.

Comprehension Refactoring

This is similar to Litter-Pickup. If a developer found that the codebase contain incomprehensible code, either due to gibberish variable names, function names or other causes. The developer then rewrite the code to make it easily readable.

Preparatory Refactoring

This usually happens when a developer is working on adding a new functionalities and find that a certain logic can be rewritten so it can be more clear and understandable. Something he/she stumbles along the way. He/she then decide to refactor those code because it will benefit him/her in the long run.

Planned Refactoring

As the name implies, the team decides to set a certain time during development phase to check their code.

Long-Term Refactoring

This is normally done when the basic fundamental of the codebase changes significantly which requires a lot of time and effort to execute.

In a developer team, it is a good idea to implement and enforce refactoring into the process. Everyone on the team is responsible for the codebase. This will make the code easier to understand and maintain.

The goal of refactoring is clean code. The effect of a clean code is faster delivery.