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

Answer 1

Continuous refactoring. You have to refactor as you go, especially at the design level. When you see broken code or design, be prepared to fix it. This is often a case of fixing something that isn't broken, per se. Except that it is... it's just not manifesting it's brokenness... yet.

Answer 2

I think the main point is when you say

you just want to rewrite everything from scratch

Just embrace it.
Use as many unit tests as possible, then let refactoring be a common practice.
Automated and unit test will ensure that changes will not introduce regressions; devoting a certain percentage of your time to refactoring old code (and this means, less new features!) ensure the existing codebase will not get old, or at least not so fast.

Answer 3

tracking defects and performance of various parts of the system will allow you to identify problems. As systems are changed poorly designed or written functions or modules will have a higher rate of defects. When a "problem" module is identified a decision can be made to rewrite the module (NOT the application).

Answer 4

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.

Answer 5

Code reviews, coding standards, and firm policies.

The following is applicable to our shop - since I don't know what sort of shop you have, your mileage may vary. While moving to Team Foundation Server, a large part of our focus was on maintaining code quality - or at least helping to maintain quality in any way possible. Some examples of what we are adding:

• Code Review Workflow - Enforces code review as part of the process. Contains a policy that will prevent check-ins from happening if the code has not been reviewed.
• TeamReview - Makes code reviews less painful by providing a complete "inside the IDE" experience.
• Check-in Policies (in general) - Many cool goodies available for control the flow of code. Things like making sure that public and protected methods are documented prior to check-in to making sure that no work can be checked in without a corresponding work item.

Like I said, if you are using a different platform, maybe the tooling available and what you can do is different. But don't rule out tooling to help in any way possible. If you can use it to improve, control, and audit your workflow and the items that move within it, it should be at least worth considering.

Remember, any changes in process are going to involve pushback. The way that we have helped ease this is to build the policies into the training for the transition from our old version control / defect tracking system.

Answer 6

I do not think it is normal. It is really hard to fight this thing when it was there for a couple of years.

The only way to avoid it is to change the attitude:

“The attitude that agile developers have toward the design of the software is the same attitude that surgeons have toward sterile procedure.  Sterile procedure is what makes surgery possible.  Without it, the risk of infection would be far too high to tolerate.  Agile developers feel the same way about their designs.  The risk of letting even the tiniest bit of rot begin is too high to tolerate.” Martin C. Robert “Agile Principles, Patterns, and Practices in C#”

I highly recommend to look into this book for advices. It names all "design smells", the reasons of their existence and consequences of leaving them. May this will help you to persuade your management that current situation is not appropriate.

Good luck!