How To Do Large Scale Refactoring

Posted by Vikas Hazrati on Aug 24, 2010

Sections

Process & Practices

Topics

Agile ,

Agile Techniques

Tags

Refactoring

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.

1. Back to top

   Interesting story

   by Zhao Vincent

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

   Reply

2. Back to top

   insde link

   by Christian Bewernitz

   Just looking at www.infoq.com/presentations/Domain-Event-Driven... which reminded me of this article.

   Reply

3. Back to top

   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.

   Reply

4. Back to top

   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.

   Reply

5. Back to top

   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.
   
   www.hexaid.com/blog/2010/10/16/things-to-consid...

   Reply

6. Back to top

   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 scg.unibe.ch/download/oorp/

   Reply

• Older >