2

Q:

Lately ,i asked for testing a code ,,to detect the bugs and fix the problems ,,i find many problems ,, but the main problem here is the code it self ,, spaghetti code many many code lines and the tracing to fix problems is so difficult ,, plus some code is copied and pasted from the internet as it is without any modification,, no documentation is possible to this code,,the performance is so bad due to the heavy using of viewstate in every thing,, and it takes me a lot of time to fix the problems ,, and iam afraid of after all this time still other bugs may appear in the future .. how to handle this case ,,any advices concerning this issue will be a great help.

Anyname Donotcare
  • 11,113
  • 66
  • 219
  • 392

5 Answers5

6

Start refactoring. This will not make only the code better readable it will also give you a btter understanding on how it works and what it does.

codymanix
  • 28,510
  • 21
  • 92
  • 151
3

That's a very common situation - software was developed for some years and by many different developers and now you have to support it. You should fight the will to throw it away and rewrite the whole application - it is a big effort and chances are big that you will do many mistakes that are already fixed in bad code. See Joel article for more explanations.

In my experience the best way is to refactor the code. However it involves writing a lot of tests - unit, automated acceptance - and it will take almost the same time as rewriting, but it will be less pain

Sergii Pozharov
  • 17,366
  • 4
  • 29
  • 30
3

I think the mentality for working with spaghetti code is summed up quite well in Refactoring by Martin Fowler.

The picture that comes to my mind is surgery: The entire patient except the part to be operated on is draped. The draping leaves the surgeon with only a fixed set of variables. Now, we could have long arguments over whether this abstraction of a person to a lower left quadrant abdomen leads to good health care, but at the moment of surgery, I'm kind of glad the surgeon can focus

Basically what that means is start small, and update a single part of the code at a time. Little changes will add up to good, structured code in the future.

Of course, if there are major problems with the entire architecture, you may have to heed Cybernate's advice and start from scratch (unpleasant as it may be).

Greg Buehler
  • 3,897
  • 3
  • 32
  • 39
1

I would also write unit tests as well as refactoring as codymanix said. This does a couple things:

  1. As you refactor, you will have some check that your refactoring won't break things.
  2. Writing the tests is a good way of learning the domain knowledge embedded in the code.

Of course, there is an inherent catch-22 with adding unit tests to spaghetti code: it is usually hard to unit test, and you need to refactor it to be able to make it testable. But if you go bit by bit and start with the low-hanging fruit, usually you can make it readable.

James Kingsbery
  • 7,298
  • 2
  • 38
  • 67
-1

Scrap the existing code and start afresh.
That involves lot less effort comparitively.

If that's not a possible option start with Refactoring using tool like ReSharper that will give a good start.

Chandu
  • 81,493
  • 19
  • 133
  • 134