Home » Software Development » Refactoring vs. Redesign

About Sebastian Malaca

Sebastian Malaca

Sebastian is an OOP enthusiast. He constantly deepens his knowledge in topics related with clean code and code quality. He’s also speaker and contributor to several blogs about software development.

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.

Motivation

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.

Complexity

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.

Timing

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

RefactoringRedesign
  • Readability and Understanding
  • Atomic changes
  • Class as a starting point
  • Ad hoc
  • Improvements and Extensions
  • Complex changes
  • Dependencies
  • Planning
Published on Java Code Geeks with permission by Sebastian Malaca, partner at our JCG program. See the original article here: Refactoring vs. Redesign

Opinions expressed by Java Code Geeks contributors are their own.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

 

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

 

and many more ....

 

Receive Java & Developer job alerts in your Area

 

Leave a Reply

Be the First to Comment!

Notify of
avatar
wpDiscuz