Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Does the frequent change of requirements lead to spaghetti code? [closed]

If the requirements are changing frequently and you want to deliver your code in time so What is the best solution or methodology used to overcome going to spaghetti?

like image 692
Ahmed Avatar asked Jan 27 '09 06:01

Ahmed


People also ask

What causes spaghetti code?

Spaghetti code is a pejorative phrase for unstructured and difficult-to-maintain source code. Spaghetti code can be caused by several factors, such as volatile project requirements, lack of programming style rules, and software engineers with insufficient ability or experience.

How does a computer program become spaghetti code?

Typically, spaghetti code occurs when multiple developers work on a project over months or years, continuing to add and change code and software scope with optimizing existing programming infrastructure.

What's wrong with spaghetti code?

Spaghetti code is when the code you work with is unstructured by nature, tightly coupled, and contains an unnecessary amount of mental translation between reality and its representations. The issue with spaghetti code is that the lines composed for the software are not easy to mentally digest.


1 Answers

What is your definition of spaghetti code? For me, spaghetti code is a too long, unstructured and chaotic method/function. This does not happen due to changing requirements, but due to developers' laziness. If you have to rewrite a method because things have changed, you can also clean it up directly without much overhead.

If you mean a badly designed object structure instead, you can be right. If requirements change too fast, you will easily end up with classes that no longer do what they were intended for, bad object hierarchies, and the like.

There are some tipps to avoid this:

  • Don't overdesign in the beginning. Try to keep your methods, classes and class hierarchies as simple as possible to make changes less difficult.

  • After a requirement changes, don't start implementing it right then, but take a step back and look if your code structure needs to be changed before the new feature can fit in.

  • Communicate to your client, that the change requires some time. If you know that they know that changing the requirement also implies changes in the structure of your code, you will have less pressure to squeeze your code into existing structures.

  • Always refactor while coding. In my experience, the small refactorings like moving redundant code from several places into a single method or class are most effective to keep your code clean. Be always on the lookout for code smells and remove them as fast as possible to make your work easier. This takes some experience, but now is the right time to start training this :-)

  • Like krosenvold said, play it safe by adding test cases to your code to take away your fear of big changes. Having worked on a large legacy system myself, I know this fear and what it feels like to work without a safety net. When you work on your safety net first, It becomes less of an adventure to make neccessary changes.

like image 103
Sebastian Dietz Avatar answered Sep 29 '22 23:09

Sebastian Dietz