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

Solution 1:

Ruthless diligence combined with constant unit testing is the only way to prevent spaghetti code. Even then it's only a band-aid solution. As soon as you stop paying attention out comes the pasta.

Very often I find that spaghetti code is introduced because someone is just plain being lazy that day. They know there is a better way to do it and just don't have the time. When you see that happen there is only one thing to do.

Call them out on it and ask them to change it

I find that pointing out the better way during a code review is usually enough to get people going. If they check it in and I feel strongly, I'll refactor it myself.

Do I occasionally come off as a little bit eccentric? I'm sure I do. Frankly though I don't mind. I'm not a jerk about it and approach this in the best possible social manner. However letting bad code get checked in pretty much assures that I am going to have to debug it at some point in the future. I'd rather take a little flak now and get the right code in.

I also feel that a culture of unit testing also helps prevent spaghetti code. It's much harder to unit test spaghetti code that well factored code. Over time this forces people to keep their code somewhat factored.

Solution 2:

I believe the key to avoiding code rot lies in sound bottom up design and implementation methodologies (I believe it so strongly that I named my business - Think Bottom Up - after it!). The tools of choice here are:

• Programming by contract
• Layered design
• Focus on decoupling
• Always build with reuse in mind, looking for generic solutions
• Keep frameworks lightweight, simple and focused

As suggested by other respondents, you need to catch problems early. With green developers, this means mentoring (pair programming is great here) and reviews (code and design reviews). With more senior developers, this means vigilance.

Most of all, do not be afraid of refactoring. If refactoring scares you, you're already sunk. If refactoring is seen as "bad", then there is something wrong with your business.

When you fix something, fix it properly. I use the term "fux" to describe a fix that was done the wrong way: it just "fux" your code base.

Cheers,

Dan

Solution 3:

20 to 50 developers is probably the problem. That is pretty high and would need a lot of management and resources to keep everything in check.

I would consider splitting the project up into smaller reusable segments. Abstract certain layers away from the core system.

Solution 4:

Create "firewalls" between different areas of the code. You do this by defining different areas or layers of code, and defining a single API (in Java, this is usually done with an interface) that each layer responds to. There should be bare-bones intefaces or classes that the API uses, but which "know" nothing about the internals of those layers. For instance, the gui should not know or care how you store data, and your database shouldn't know or care how the data is presented to the end user.

These APIs don't have to be cast in stone - you should be able to add things as necessary, as long as you make sure you aren't polluting the firewalls.