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

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

Start creating unit tests, this will help you decouple your code and avoid follow up errors on bug fixes. It you have good coverage it will make it easier for you to remove unused code as well.

Answer 5

Don't allow code to be committed until at least two pairs of eyes have seen it.

Answer 6

I think the loose coupling you can get with full-blown use of dependency injection is a technical feature that can help a lot. When you break apart the pieces of the application you're less likely to get spaghetti resulting from "interesting" re-use.

You may be headed for excessive fragmentation instead, but that's another issue and less of global structural problem.