The topic "spaghetti code" is a huge one. Basically, it means, that it is hard to figure out what a piece of code does, even for experienced developers. And this is also highly subjective. And the reasons why a piece of code is considered as "spaghetti" are different. The common reasons are: many deep nested loops/if-else-constructs, bad naming of variables, methods, procedures, the usage of many mutable global-/static variables or a class, method, procedure does too much etc.
Can you "fix" spaghetti code? The answer is: it depends. Because the reasons why the spaghetti code does what it does are also different.
Are the calculations, which the spaghetti code has to do also very complex? If yes, then you will propably not be able to "fix" it with a rewrite. Maybe you can make the spaghetti code less spaghetti, but not more. This is mostly the reason for many deep nested loops/if-else-constructs. If you have ever wrote code, which calculates the salary of a employee based on taxcard, health insurance etc. then you propably know what i mean.
Bad naming? The hardest thing is to find a good name. And yes, naming is hard.But if you have a good name for a variable or method then use the refactoring funcionality of your IDE.
And bad naming can turn even trivial code into spaghetti code. If you name your method "calculateSpellCriticalHit" then the devs will know what this method does. But if you name it "calculateHit" then they will need to look into it because this name is too generic.
But it seems to me, that "spaghetti code" is not the reason why they have often much pain to improve some things. I guess, they have really f*cked up the persistence layer. The persistence layer is the piece of code, which communicates with a database server. And because it is so fundamental, the chances are high that if you change something here then it will break some things in the software if you do not pay attention. And unfortunately nobody knows how the persistence layer of the game looks like. But there are also methods to mitigate the pain if you really need to make changes: use a statically typed programming language and use an ORM framework and write integration tests. Because there are many tools, which can help you identifying incompatible changes. If they do not use them then they have to analyse the whole code base manually (basically via CTRL+F) and identify the places, which could break with the change. If the codebase is huge then this is very personal ressources intensive.
Cheers




Reply With Quote

