Is there a way to avoid spaghetti code over the years? [closed]

Answer 1

No

:)

Answer 2

The biggest problem in the software industry is that the quality of programming code is viewed as a subjective issue. Without some well-defined metric, just being neat and tidy, and following the conventions isn't enough to ensure that the quality is acceptable.

There are attempts to change this, but they are unlikely to get sufficient interest or acceptance primarily because the long established culture of programmers is in trying very hard to stay away from anything that resembles engineering. The "pure art" philosophy of programming means that your 20-50 developers are all going to flail at the code in their own unique fashion, so that no matter how good the individual coders, the sum total of the group's effort is always going to be "a big ball of mud".

To avoid this, either get all of the coders on the same 'page', make normalized code part of your convention, or chase after jobs were the development teams are smaller (1-3 people) and you're the big kahuna. Someday the big teams may find a way to build better stuff, but until then even the best of them are extremely lucky if they can just get close to 6 out of 10. We build low-quality software because that's what we've set up our industry to do ...

Paul.

Answer 3

More code reviews and perhaps code ownership.

If you just hack some random code then you don't care as much as for the code you "own". If it's your responsibility to maintain one module of the project, you want to shine.

And code reviews is a time when you show your code.

Answer 4

You have to follow software development practices closely. There have to be code reviews, and unit test that constastantly make sure that the updates are affecting other things in the system. 20 - 50 devs is a lot, but it can be done. Implementing good processes is the only thing that will save you in this environment. Enforced coding standards are also key.

Answer 5

It sounds like many are not following some basic tenets of encapsualtion and good design.

Keeping things isolated and unreliant on other parts is essential to avoid the problem you describe. You might need some higher level designer or architect. This is a typical scenario where people have justified some draconian processes and change management. (I do not advocate that)

You need to avoid dependencies and interrelationships and define and use public interfaces only. This of course is an oversimplification, but you will probably learn a lot by some metrics on your code - complexity of classes, public methods, UML diagrams built from reverse engineering the code, etc.

Answer 6

Refactoring

Strive keep the design as clean as possible. This is not easy, but it's worth the effort.