Sunday, November 12, 2017

Refactoring vs. Redesign

It often happens that developers use words Refactoring and Redesign interchangeably. Why? I think that is because in both cases we are ending with the same result - code that is changed, but it does exactly the same thing as it was capable of doing at the beginning of the process.

Yet, in my opinion those words are not exact synonymous and before we will start to refactor the code it is good to know the difference.


We are refactoring the code to make it more understandable, to make it more readable. We are doing it to improve the ease of reading the code and understanding it.

On the other hand we have redesign and motivation standing behind it -- they are different from refactoring. We are redesigning our code when we want to change functionality, prepare the existing code base for expansion.


Each refactoring is a small change in code base, like renaming a method. And each is atomic in that it does not require anoher step to bring value. Of course, you can keep in mind some more refactorings which includes more commits, but it can be stopped at any point without any negative impact on the code base.

And there's redesing. You shouldn’t touch the code without having a plan. You need to know where you are going and you should not stop before you will reach the point. The whole redesign is done when the whole plan is finalized.

The Scope

Starting point of refactoring is a class, a method. You may rename it, extract code to the separate class, but the scope of the change isn’t usually bigger than a two, three files.

Redesign is mostly about communication between objects, about how they interact with each other. It means that usually redesign results in changes in many classes, the way they communicate with each other.


You should refactor your code on a daily basis, whenever you spot a place for improvement in the code base. It happens when you are working on introducing something new or changing something existing. During this work you just notice part of the code and you decide to refactor it. It is not your main goal, you are doing it additionally.

When you are redesigning a code, redesign is your goal.
There is even a chance that during redesign you will do a few refactorings as well.

Summary table

  • Readability and Understanding
  • Atomic changes
  • Class as a starting point
  • Ad hoc
  • Improvements and Extensions
  • Complex changes
  • Dependencies
  • Planning