So afraid to write bad, spaghetti code, I ended up writing no code at all. This thread made me realize that it's better to have a working profitable project with bad code, than a perfect unfinished project, with meticulously chosen design patterns. Afraid of being judged for bad code, I could not start until I had the right architecture. I'm glad I read this. This is developers therapy.
I've sadly come to realize (after witnessing on many projects) that there's a pattern that goes like this: * Team A writes code quickly. Not bad code, really, but they take shortcuts everywhere they can. They don't have the strongest tests, they don't generalize for all the known use cases, etc. Their code goes to beta and gets users and makes progress. * Team B deliberates and deliberates. They try to avoid taking s…
A project with a single 11,000-line code file
151–160 of 346 posts
Re: A project with a single 11,000-line code file
#152Earlier quoted context omitted.
I've sadly come to realize (after witnessing on many projects) that there's a pattern that goes like this: * Team A writes code quickly. Not bad code, really, but they take shortcuts everywhere they can. They don't have the strongest tests, they don't generalize for all the known use cases, etc. Their code goes to beta and gets users and makes progress. * Team B deliberates and deliberates. They try to avoid taking s…
There's a YouTube video about beginner musicians vs intermediate vs advanced. The beginner uses simple chords The intermediate uses advanced chords, crazy fills and runs and riffs. The advanced uses simple chords
Re: A project with a single 11,000-line code file
#153Earlier quoted context omitted.
You sometimes can. Maybe for any legacy code base someone could, but I have tried and failed on more than one occasion. Some people’s thought process is just perversely different to mine and I keep feeling, oh, this is the layer where that happens, but no every time I have an aha moment I am disillusioned.
If you don't have a test suite, you can't know if you're making progress or making things worse. Learned repeatedly from painful experience.
A lot of edge cases and race conditions would easily slip through, also a different set of edge cases or race conditions you never considered and therefore never tested for in your first version could pop up in your rewrite.
Re: A project with a single 11,000-line code file
#154I remember many years ago coming across a reimplementation of the server side for a popular MMORPG of the time, reverse-engineered from the client (which was Flash) by what was likely a teenager --- it was over 100k lines in a single file, written in Visual Basic. Global variables everywhere, short names, and not even indentation. All the account data was stored in flat files, there was no actual DB. No "best practic…
Ironically, this is a description of hacker news itself. https://github.com/shawwn/arc/blob/arc3.1/news.arc (HN has indentation, though.) It’s important to realize that this is good design. It’s hard to separate yourself from the time you live in, but the rewards are worthwhile.
Re: A project with a single 11,000-line code file
#155It really speaks to the state of software engineering when there are ample comments here defending this practice. This is virtually indefensible in my book, as it screams technical debt and strongly suggests that there are much deeper issues hiding in that codebase. Personally I would not be willing to work on it without first addressing those issues.
Re: A project with a single 11,000-line code file
#156Re: A project with a single 11,000-line code file
#157Earlier quoted context omitted.
Lol, reminds me of the meme: var a = true; if(a == true) then return true; else if(a == false) then return false; Or something like that.
i hate to say that I've definitely written code like that. not any time recently, thankfully (at least I think)
This is why I’m always loathe to criticise stuff I see on WTF.
Re: A project with a single 11,000-line code file
#158Earlier quoted context omitted.
I've sadly come to realize (after witnessing on many projects) that there's a pattern that goes like this: * Team A writes code quickly. Not bad code, really, but they take shortcuts everywhere they can. They don't have the strongest tests, they don't generalize for all the known use cases, etc. Their code goes to beta and gets users and makes progress. * Team B deliberates and deliberates. They try to avoid taking s…
Something this reminds me of that I've been doing lately when stuck on a particular problem is just coding something. Even if it's the most shittiest, inefficient and naïve solution. More often than not I either discover a more proper solution along the way or just realize my shitty solution actually wasn't all that bad to begin with.
Re: A project with a single 11,000-line code file
#159Back in the days at Zynga, there was this ritual that new members of the STG (Shared Tech Group, which developed the game engine stack) had to try to refactor the road logic code. Suffice it to say, it's a 28k LOC file that was so bad, it could even hold up in court as evidence that a South American company stole the code of Zynga's -ville games. We could reproduce each and every single bug and its effects 1:1 in the…
To be fair, the first step towards refactoring is understanding the existing code -- ideally, knowing everywhere it is used, all of its behaviors, and importantly, its history, so that you don't break anything, and so that you don't reintroduce bugs that have already been fixed over the years. Or, in lieu of all that, a robust automated test suite. This cannot be done with a file containing 28k lines of code. That is…
Re: A project with a single 11,000-line code file
#160Earlier quoted context omitted.
I've sadly come to realize (after witnessing on many projects) that there's a pattern that goes like this: * Team A writes code quickly. Not bad code, really, but they take shortcuts everywhere they can. They don't have the strongest tests, they don't generalize for all the known use cases, etc. Their code goes to beta and gets users and makes progress. * Team B deliberates and deliberates. They try to avoid taking s…
+1 I had a lot of trouble trying to explain this to juniors. The most important things is to have code that is easy to refactor when you know what you're doing (i.e. everything is working properly). Juniors I worked with had a nasty definition of a pretty code being split into a hundred files, each no longer than a screen, and each function no longer than 5 lines. The onboarding of new devs to such code was way worse…
This whole post is about how refactoring doesn't matter because your project's development lifetime isn't long and wide enough for maintentance to matter.