Over a million developers have joined DZone.

The Difference Between Refactoring and Redesign is 10 Minutes

· DevOps Zone

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

Ten minutes is a lot of time. It is just enough to drown. If you're young it can be enough for something quick, like running a mile. And ten minutes is the difference between refactoring and redesign. Anything that takes longer than ten minutes is not refactoring. That is a redesign.

Based on this I could imply that refactoring is what you can do while holding your breath, but that won’t work. First of all, there are only a few men who can hold their breath for ten minutes, and usually they are not good at programming. On second thought, you need brain power to do programming, and free-diving is not about deep thinking, it's about deep ... sinking.

So now we know that redesign is something like refactoring, but it is longer. Complete refactoring is redesign. What about partial redesign?

Partial redesign is practiced when you can't perform a whole redesign and, therefore, you chop it up. There can be multiple reasons for not being able to perform the whole redesign in a single sprint (besides being old). There may not be enough time. That is a key indicator: if you planned to redesign in a sprint and the plan says that it won't fit, you can be very sure, no matter how badly you estimated, that it will not fit.

When you chop up a redesign into small chunks, you have to ensure that you have working code after each chunk is swallowed. This is also a difference between redesigning and refactoring. When you do a refactor you continuously have working code. (Or not.) You can also do a redesign that way, but sometimes you just decide not to do that since it may be too expensive and require lot of temporary code that is needed only to keep the code alive during the process, and is not needed before or after the redesign. (We're lucky in this respect. When doing open-heart surgery there is no such option.)

So you do a partial redesign. And then comes the experience: If you are successful with the first drop of the partial redesign, it will stick at that point. There will be no further time to continue with the rest of the redesign. Trust me, I am an engineer: It is the way it is going to be. In other words, if the drops do not deliver value individually you're better off not doing them at all.

Making it clean and clear: If there is a scout camp that has to be redesigned and you want to replace the location of the kitchen and the latrine, don't start with the kitchen, because when you stop after the first partial redesign you will have two latrines and no place to eat. And then you will be in deep trouble.

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today


Published at DZone with permission of Peter Verhas, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}