How To Do Large Scale Refactoring

| by Vikas Hazrati on Aug 24, 2010. Estimated reading time: 3 minutes |

Refactoring by definition means changing the internal structure of a program without modifying its external functional behavior. This is mostly done to improve the non-functional attributes of the program thus leading to improved code readability and maintainability. However, refactoring on a large scale often gives jitters to even seasoned Agilists. The Agile community discussed some ways of handling the large scale refactoring.

In a recent discussion, Andreas wanted to know the best way out of the possible three for doing a large scale refactoring. His ways included,

  • Big Bang - Define the structure for the final state and push code to its ultimate home.
  • Divide and conquer - Try to separate the big ball of mud in to two pieces. Repeat until done...
  • Strangling- Strangle the classes

Most respondents agreed that Big Bang was almost never going to succeed. Aaron Digulla suggested that he had been using the Strangling approach for his entire career. The idea is to gradually morph the bad code into shiny new code which has a test harness around it. The advantage of this strategy being that since you start slow with smaller pieces, the risk is usually small. David Hall and Shane MacLaughlin stressed on the importance of doing a small divide and conquer approach by writing enough tests around any portion of the program which is touched. Some people suggested a complete rewrite but as per an earlier post on InfoQ, that has its own set of challenges.

Sibylle Peter and Sven Ehrke mentioned that they follow an approach of conducting an assessment and creating a master plan of refactoring for large scale refactoring. For each refactoring step, they follow the following three steps

  • Analysis: definition of the desired result and HOW to achieve it.
  • Implementation: application of refactoring techniques to alter the code accordingly.
  • Stabilization: application of methods, which ensure that the result of the implementation is durable.

Another approach which is gaining momentum for large scale refactoring is the Mikado Method. The Mikado method has its history associated to the work done by Daniel Brolund and Ola Ellnestam and draws its name from the Mikado game. According to this method,

Code changes are like the Mikado game. When you want to make changes to a code base, you can rarely make the exact changes you want right away. You have to prepare some, move code, extract classes, and much more. Picking up the Mikado on your first grab is a rare thing! More often you make a sequence of moves before the Refactoring Mikado is available, working your way systematically to the bottom of the pile, to reach your goal.

Mikado approach starts by keeping the end in mind. For any code base which needs to be refactored, the idea is to create a dependency graph starting with the end goal. Next step is to identify the immediate prerequisites to reaching the goal, and continue identifying dependencies in that way until there is a point, called a leaf which has no prerequisites or dependencies. This mostly is the best starting point to begin the refactoring. Once there is a dependency graph, the central idea is to work back from the leaves toward the goal, step by step.

The approach strongly suggests the importance of Undo, where teams should not have fear to revert and throw away the changes. It also recommends not to get into analysis paralysis and instead start with a naïve step and then understand the consequences. The draft copy of the book on Mikado method is now available.

Thus, though large scale refactoring is hard to do but the key lies in identifying the starting points and then treading the path in small steps.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Interesting story by Zhao Vincent

Use a lot of examples to illustrate...
Good to think it over

insde link by Christian Bewernitz

Just looking at which reminded me of this article.

Extreme Refactoring by Steve Eckhardt

I've been assigned to maintain and enhance 300k lines of C code (that's right, no classes and lots of global variables). Many functions do things that are embarassingly parallel, so huge performance increases are possible with threading. I can't afford to rewrite the whole app, but I can hardly afford not to. Wonder what Joel or Martin would say.

Refactor into something better by Martin Wickman

Thanks for a great article, lots of good input!

Large refactorings are fun and all, but just make sure you're actually doing things differently this time so as to not end up with the same problems again: The big rewrite.

Some other aspects of refactoring by Gabriel Belingueres

Interesting article.

You may want to see this post with some decisions that people has to make BEFORE doing big refactorings.

Take a look at Object Oriented Reengineering Patterns by snoobab kicker

For a good starting point maybe taking a look at Object-Oriented Reengineering Patterns book. It has many useful techniques and processes. Topics covered include initial encounter, detailed model capture, tests and migration strategies.
Download available at

Important topic, what about metrics guiding refactoring? by Amr Noaman

I have worked on another pathway for refactoring legacy applications. I called the model 3Q's, have a look:

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss