#Spaghetti Code or #Legacy Code: Unavoidable Problems with Outsourcing

Spaghetti Code refers to unstructured and hard-to-maintain code sources. You can simply understand like the code tangles as spaghetti noodles. They can be a series of code sources which hook various modules or classes together. Besides, the code flow also makes it hard to understand and read. Therefore, development teams take a longer time to maintain, upgrade or build further features. This Spaghetti code is considered as an anti-pattern that most developers should avoid.?

Legacy Code is a section of source code that is no longer supported although it has been used for a long time. However, Legacy Code seems not to be or hard to upgrade. Normally, the Legacy code is converted into a new programming language and innovative platform.?

In reality, developers having to work on one or two kinds of code sources probably get in trouble. Nevertheless, it is also an interesting challenge for them to explore a system that has been utilized for years. Interestingly, there might be amazing features that we can take advantage of later on.?

So should we build a new one??

This is an optimum option for most developers when they take over legacy code-based or Spaghetti code-based projects. This approach might be a good one at the beginning:?

- Based on the existing system, we perceive what the system should have or what features need to be figured out.?

- From that, we can easily design and choose the appropriate technical stack matching projects’ requirements.?

- Developers also understand more business models, then get practical lessons from the previous mistakes to build code better.?

HOWEVER, this way also has hidden drawbacks:?

- Development teams will take more time to build the system again from the start. Also, we can not add new features or bring value to enterprises.?

- There are hidden bugs that are fixed in the old system, however, when building codes from the beginning we might miss them. Those bugs can appear again in the new projects.?

- During the re-building code process, requirements continue changing. Impossibly, the new system also has code sources that are messy and unstructured like the old ones.?

Other possible problems:?

- Copying common codes is one of the perpetrators in the old system. You will see a similar pattern of logics which are scattered over many modules since developers are afraid of touching the beginning code sources. “What if it’s wrong?” - It is a fear, but it will not be a legitimation of copying common codes. You might see that copying common codes will save time and effort at the moment, however thinking about those logical patterns will get problems if they exist in different 20 places.?

- Deciding which one should be kept or which one should be removed will definitely be a skill based on your experiences. If code can handle a complex issue, it might be kept. Besides, if the code acts as an alternative solution for removed issues, it should be discarded. We also have to consider possible benefits and drawbacks. If you clear the code without understanding its purposes, it looks like you throw a rope randomly out of a complex machine - that leads to a great system or you can make everything boom.?

- Refactoring code is like an intermediate platform, so you don’t have to choose between keeping code and rewriting everything. Moreover, you can continue developing different functions, or changing the way of building codes. Refactoring code mean that you make code more clean, structured and easy-to-understand without changing the attributes of codes. You also conduct a test to ensure the code operates as expected before or after you change.?

So what should you do now to make code cear and easy-to-reuse??

The most important keyword is to focus on materials, tests and reviews.?

- Detailed documents: Writing documents is boring compared to building code, so we might feel lazy when doing this. You don’t have to write documents for each file or each code line, SHOULD focus on building software architecture and modules, common workflows, or deployment stages and it’s great.?

- Unit Test and Comment: Writing unit tests helps people easily understand how a function statement works and what is the possible result? Great comments help you understand why code sources are built and written like this. Besides, thanks to unit tests, developers feel more confident when refactoring codes without creating more bugs.?

- Code Review: Before committing, other developers in a team should review the code, find more errors and propose innovative solutions.?

Conclusion

Don't shy away from legacy code. Use the opportunity to study it, understand it, and improve it.