Strategy for large scale refactoring

Question

I\'m currently working in a piece of code where both logic and data access are present in the GUI classes. Obviously, I would like to improve on this situation.

The

Answer 1

I stumbled upon "the Mikado Method" that seems promising for attacking problems of this nature.

http://mikadomethod.wordpress.com/

There is also a talk about the Mikado Method from Øredev 2010.

http://oredev.org/2010/sessions/large-scale-refactorings-using-the-mikado-method

Answer 2

Never attempt "Big Bang". It almost always blows in your face, since it's a high-risk, desperate measure when everything else has failed.

Divide and conquer: This works well ... if your world has only two sides. In real software, you have to conquer so many fronts at the same time, you can rarely afford to live in a black-white fantasy.

I guess I've been using something like "Strangling" for most of my career: Gradually morphing bad old code into shiny new code. Here is my recipe:

Start somewhere, it doesn't really matter where. Write a few unit tests to see how to the code really behaves. Find out how often it does what you think it does and how often it doesn't. Use your IDE to refactor the code so you can test it.

After the first day, make a guess whether you've started at the right place to take this monster apart. If so, go on. If not, find a new place and start over.

Advantages of this strategy: It works in small steps, so the risk can be kept in check and if something breaks, if has to be in the code you've been working on last week.

Disadvantage: It takes a whole lot of time and you will feel frustrated because often, progress will just seem so slow until the "knot" pops and suddenly, everything starts fall into place as if by magic.

Answer 3

For me it depends on the situation.

If it is a very small project I'd be tempted to just rewrite it from scratch...however you don't often have that luxury.

Failing that, I'd go for chipping away at it piece by piece. I'd write unit tests to verify the existing functionality and slowly use TDD to transform the code into an elegant and well designed system. Depending on how long this process is going to take it will probably start to look like the StranglerApplication you mentioned above.

BigBang is very risky as you have no easy way of verifying that the updated system does the same thing as the old one.

Divide and Conquer is less risky than BigBang...but if its a large enough system it can wind up being just as problematic as BigBang.

Answer 4

Depends on whether you have to have always a working state, so that you can bug-fix and deploy whenever neccassary, then Devide and Conquer would be a good solution. If you can maintain the old code, while working on a new one (and have the disciplin to apply bug-fixes to both code-bases) a re-write may be a better solution.

Answer 5

If by refactoring, you mean improving the code without modifying the functionality, I'd start by creating an automated regression testing base line. There are plenty of tools out there to help with this. I use TestComlete though there are good cheap alternatives.

Having established a regression test baseline, personally I would then go with divide and conquer, as it in my experience it is the most likely to succeed. Once you have a testing baseline, it matters less which approach you choose.

Answer 6

Big bang / Big re-design / rewriting the SW ... or whatever other names will not work for a living SW. The reasons are:

• You still need to support the existing SW with (probably) the same resources you have.

• You probably do not have the requirements for rewriting. Your old code has all the requirements embedded inside it. None of your engineers know all the SW domains and all the requirements.

• Rewriting will take time. At the end of this time you will find that the existing SW has changed to support things that were required during this time. your new SW actually split from the original and merge will be needed (which will also take time).