saetia
saetia
About
- Username
- saetia
- Joined
- Visits
- 0
- Last Active
Comments
-
@BigTimeGamer said:
https://forum.deadbydaylight.com/en/discussion/comment/1704722#Comment_1704722
You cannot be trying to say that DBD isn't spaghetti code, its a well-known thing lmao
Have the devs admitted that? Have you seen the code? Has the source code leaked? Am I missing something here? Obviously, I haven't seen it, I don't know what their code base looks like, I'm just arguing you can't say it's spaghetti code unless you've seen it and bugs can happen regardless if it is or isn't.
@Pawcelot said:
https://forum.deadbydaylight.com/en/discussion/comment/1704540#Comment_1704540
How could you not call it Spaghetti code when updates break so much stuff, even things in areas where nothing was changed.. like the Spirit now making sounds when phasing?
Please reread my example. And again, when developers do stuff it's usually in sprints where multiple things are being worked on, again: that doesn't mean it's spaghetti code that breaks it. If an abstract or base class is used for all killers, and they fix a bug from one killer in that abstract or base class and it affected spirit, that again is because it's spaghetti code. It's literally the paradigm of oop to have code being reused when you can to limit spaghetti code.
Edit: if I get proven wrong and shwon proof it is spaghetti code, cool, I'm just offering alternative reasons as a dev and I'm giving devs at least a little benefit of the doubt because I work in the field.
-
@RockoRango said:
https://forum.deadbydaylight.com/en/discussion/comment/1698528#Comment_1698528
How is someone supposed to magically know you're 17 and don't know much about development? I'm only a year older than you, yet I've been taking classes at both my school and an external college for more than a year that massively increase my understanding about the subject.
As a software engineer I'm going to tell you right now that what you learn at school/college is nothing like actual development. Little/no colleges teach about how real world engineering is like and you only really start to know once you get a job or internship. That is why imposter syndrome is such a huge huge huge thing in the field.
Anyways, I'm arguing against your point #2 - we don't know if their code is spaghetti because something changes and breaks. There are so many factors in this.
DBD is written in presumably C++ because it uses unreal - I'm gonna give a situation I've been in as a dev in c#, which is also an OOP language. Let's say we have a base class - BaseSurvivor that has base mechanics for every survivor and whatever inherits from that class overrides as needed, whatever. Let's say they have a method on there that calls a static helper class that does some business logic, and we had a bug report come in that says 'hey this isn't providing what we are expecting' and we go in and fix it, but in the process we introduced a new bug. The devs and QA team go through it and test it don't find anything wrong. We ship this update out to the customers, and bingo bango we got another bug report come in because this static helper class was also used in another part of the app and had unintended consequences. That's not spaghetti code, that's just the paradigm. One of the biggest things in OOP is reusability of code, if you need to do the same thing twice, you make it reusable.
Sprints are also not just one thing being worked on, it's multiple things being worked on at once by multiple people. Blaming something broke because they fixed something could be a completely from something else even though to us, the end user, it seems that correlation = causation for the issue.
In either case, I don't particularly put blame on issues on devs on a few issues (ie this event) because usually things like this are controlled by product team and priorities and initiatives usually come from the business side of things and they are told what to do. This is why it takes forever for things to happen. Remember when they changed auras and had so much backlash? It's not just as simple as a dev or two going in and reverting things, it's an entire process. Product and project managers need meetings, determine if it's a "hotfix" or if it will go out in a regular update, devs need to estimate time/effort on the tickets created, do investigations, it needs PR reviews, it needs to go through some QA (I assume bhvr has some sort of QA, but sometimes I question that).
I think the biggest issue facing DBD is that the original devs didn't expect this to blow up and it's just had bandaid after bandaid of fixes that can only be solved by rewriting the game from scratch, and that's not a particularly easy initiative to take nor is it profitable for the business side of things to hold off on what could be a multi-year project to approve it. These are usually put in the backlogs as technical debt tickets and sit there forever and taken up randomly in sprints and not at once. Even if any new code is optimized/cleanly written/whatever, it's still on top of the base code that isn't.
TL;DR blaming devs doesn't do anything when things like the event come from above them and the business side got initiatives to hit, deadlines to meet, blaming devs for spaghetti code for changing something and another thing breaking is ignorant we don't know what their code base looks like nor do we know if it broke because something else was worked on