Rewrite or repair?

Question

I\'m sure you have all been there, you take on a project where there is a creaky old code base which is barely fit for purpose and you have to make the decision to either re

Answer 1

Just clean up the code a little bit every time you work with it. If there isn't one already, setup a unit testing framework. All new code should get tests written. Any old code you fix as a result of bugs, try to slide in tests too.

As the cleanups progress, you'll be able to sweep more and more of the nasty code into encapsulated bins. Then you can pick those off one by one in the future.

A tool like javadoc or doxygen, if not already in use, can also help improve code documentation and comprehensibility.

The arguments against a complete rewrite a pretty strong. Those tons of "little bugs" and behaviors that were coded in over the time frame of the original project will sneak right back in again.

Answer 2

Refactor unless it is very bad indeed.

Joel has a lot to say on this...

At the very least, rewrite the code with the old code in front of you and don't just start over from scratch. The old code may be terrible, but it is the way it is for a reason and if you ignore it you'll end up seeing the same bugs that were probably fixed years ago in the old code.

Answer 3

See Joel Spolsky's essay Things You Should Never Do. In summary, when you rewrite you lose all the lessons you learned to make your current code work the way it needs to work.

See also: Big Ball of Mud

Answer 4

It really depends on how bad it is.

If it's a small system, and you fully understand it, then a rewrite is not crazy.

On the other hand, if it's a giant legacy monster with ten million lines of undocumented mystery code, then you're really going to have a hard time with a full rewrite.

Points to consider:

• If it looks good to the user, they won't care what kind of spaghetti mess it is for you. On the other hand, if it's bad for them too, then it's easier to get agreement (and patience).
• If you do rewrite, try to do it one part at a time. A messy, disorganized codebase may make this difficult (i.e, replacing just one part requires a rewrite of large icebergs of dependency code), but if possible, this makes it a lot easier to gradually do the rewrite and get feedback from users along the way.

I would really hesitate to take on a giant rewrite project for a large system without being able to release the new edition one part at a time.

Answer 5

I highly recommend reading "Working Effectively with Legacy Code" by Michael Feathers. It's coaching advice on how to refactor your code so that it is unit testable.