Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Strategy for large scale refactoring

Tags:

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 current structure is basically:

  • Big ball of mud

The ultimate goal is to achieve a DDD-like structure:

  • DAL
  • Domain model
  • Service layer
  • Presentation model
  • GUI

So, how would you attack the problem?

  • 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 (as described in http://martinfowler.com/bliki/StranglerApplication.html)
like image 682
Andreas Avatar asked Dec 01 '08 07:12

Andreas


People also ask

What is the most common cause of refactoring problems?

The most common cause of refactoring problems is not in the code -- it's a lack of proper tools. Refactoring nearly always includes renaming variables and methods, changing method signatures, and moving things around. Trying to make all these changes by hand can easily lead to disaster.

What should a team do refactoring?

Refactoring Is Essential to Agile Refactoring consists of changing the internal structure of the code in a way that doesn't modify its behavior. This makes the code more maintainable and easier to understand. It enables the developers in the team to keep complexity under control.

How much time should be spent on refactoring?

Most commonly, refactoring time allotment is < 1 %.


1 Answers

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.

like image 119
Aaron Digulla Avatar answered Sep 25 '22 15:09

Aaron Digulla