How to save my sanity while maintaining spaghetti code [closed]

Answer 1

• Be slow and deliberate.
• Write tests when you can, but don't get dismayed when you can't. Spaghetti code is rarely testable code.
• Remember that everybody who edited the code before you had a good reason to do what they did. Assume the best of them, and you will likely be rewarded.
• Understand the code before you attempt to change the code.
• Take notes as you learn, and keep them up to date as you work. Keep and share them on a wiki if you can.
• Use a revision control system, make each change as small and focused as possible, and check in as frequently as possible.
• Don't bite off more than you can chew. As you are making one change, you will no doubt find something else that ought to be cleaned up. Add it to your to do list and remain focused on your original mission.
• Treat the project like a campsite: leave it in better condition than you found it. And remember that "better" is relative; you can't fix everything at once.

Answer 2

I am in the middle of bug fixes for a legacy code app. I try to never bash on the previous developers (especially since I am still learning). Everything I change I make extensive comments on so that I can find it again and so that the next person understands how the code has evolved.

Always try to remember that you can't know all of the circumstances in which the code was written. While that doesn't necessarily excuse poor programming or logic it will certainly keep your blood pressure down.

I also take every head-scratcher I come across as a new chance to learn something and/or try something new.

Answer 3

outsauce it :)

If that isn't an option, well... first, try to make heads and tails of it. For the stuff I've dealt with, this is often the hardest part. You can manually create UML, you can use some of the commercial source code "reverse engineering" tools, or you can just trace the code.

When you have an understanding of the code, it's time to refactor. Plan well. Try to write a bunch of decent tests. Then go through an iterative approach of refactoring, writing additional tests, and checking (working!) modifications back into source control.

Depending on how masochistic you are, this can be great fun or your own personal hell :)

Answer 4

Here's how I approached this problem while maintaining a 10 year old legacy perl system. To give a slight bit of background, this was some of the worst of the worst. I was initially depressed when I started working at the company because the code was so poorly thought out and laid out (and it was my first programming job). By the end of that gig I had a pretty good system though.

First of all, every new feature was added as a new module or methods. Nothing was hacked in on top of the existing code. This let me write unit tests for the new stuff, providing the confidence in it, so to integrate with the old stuff was just a matter of a line or two.

Secondly, any bugfix was implemented the same way. I'd spend some time figuring out what was happening with the old stuff (not searching for the bug), and I'd write it out as a new method (or module), and wrap it in tests, and then typically could replace.

This however only works if you've got the time, and the buy-in to get it done. If you don't, keep track of the time that you spend on any given bug. Especially where it's multiple bugs in the same file, or process, or whatever. At some point in time, it's easy to point at a given collection of code and say that this is so bad, has cost N amount of time, it's time to rewrite.

I was successful enough with this approach that I gained the honorary title "Forensic Programmer", it's also a fantastic skill to have, because more often than not the new job already has some code written :P

Answer 5

I know that in a well known insurance company I used to do sys admin for, the main pricing system used is a 25ish year old mainframe called GenZ. Since the mid nineties, I think, a new system has been in development and is currently being rolled out in beta

The mainframe, probably, worked perfectly well in the 1980s - but since the company grew, more data was added and the system needed to hold more. Patches were applied, more problems happened, and its been like that for years.

Currently, the system interfaces with at least 200 other applications used by said insurance company, and so replacing it will be a very hard job, and is probably why it has been put off for so long.

Now that the new system (called Maxx) is being rolled out, several hundred applications will have to be phased out.

Poor coding isn't about developers being afraid to do things that aren't required, its just that mostly, they don't think far enough ahead, think of the worst scenarios, or think of what it may be like for consumers, employees and developers in the future.

Answer 6

The only way I know is:

1. write tests
2. refactor
3. run the tests
4. fix what's broken
5. write tests for the new feature
6. introduce new feature
7. run the tests
8. fix what's broken

You may live through it this way.

NOTE: there are some times where it's really hard to unit test spaghetti code: 3Klines methods which generate HTML, DAOs entangled with business logic, strongly coupled classes... in this cases a good IDE with automatic refactoring (capable of extracting methods, to begin with) and some test tools like Selenium may come in really handy.