Isn't the most effective solution for traffic something in the middle? Both of these suck for different reasons.
It's mainly public transit. Trains, busses, etc
@Matriks404 it dpends on the traffic. Where I grew up any more than the first would be dumb.
Don't worry its going to get refactored any day now
I've reworked SO many systems that started clean and were obviously updated by a series of different people over a span of years. New features nailed on with apparently little understanding of the overall app. It's like, "Oh dude it was already doing 90% of what you wanted, you didn't have to add all this... <sigh>." Especially true when offshore contract agencies had been involved - to churn through jobs as fast as possible (with no other concern) they tend to copypaste sections of the app that do something similar to what's desired, and make minimal changes to them, with zero code cleanup. This leaves all sorts of misleading unnecessary code, as well as inefficiencies like grabbing a large dataset to get a single item, etc. I found things that made me literally LOL.
I just need to add 20 if-branches in 15 methods across 10 different files from 5 modules.
Our off shore contractors produce some of the worst code. But it's impossible to get work done and also be vigilant enough to reject their bad pull requests. So basically you'll end up looking a code one day that is godawful and think, "this is off shore". And yep, git blame tells you you're right.
When your management judges teams by lines-of-code written.
I feel line this would be funnier as "code updated to do 999 things"
@JackbyDev BTW, I love the Netscape profile pic.
Excellent point. Sometimes removing functionality is much more kludgy than adding it.
@JackbyDev lol
Shoutout to [email protected]
Single responsibility principal and dependency injection are your friends.
The problem is that so is the junior dev they hired to do the two seniors' jobs who left for less inhuman pay.
Code problems are usually people problems.
Also makes it easier to put spaghetti back onto the right track
You reminded me of a guy who’s always banging on about how Elm combs the spaghetti in your source code for you and the meatballs and sauce are only mixed in at compile time. He says object oriented programming is like threading the pasta through the meatballs which is OK before anything’s cooked but after that it gets too soft and entangled and the spaghetti won’t thread through so you start again rather than refactor. It was a compelling image and got me curious.
I used it for the second rewrite of a side project WebApp a couple of years ago, and I it felt like I had to do everything from scratch by hand all the time at first, but I have to admit that maintenance has been an absolute dream compared with the old codebase. New features, changed functionality, it’s always good and you don’t need to reunderstand everything because it’s all so separated and I told him he was right. It writes the css for you and I kid you not, I did not miss that flakey nonsense one bit.
Our boss is shit scared of anything even a little bit different, though, so he noped out hard when he saw the syntax and got all shouty about all the whitespace and arrows on the big branching statements before launching into a sermon about how you can’t have a corporate look and feel unless you use css. I lost quite a lot of respect for him that day.
Our code at work is so like the bottom picture. You have absolutely no idea whether you just filled someone's underpass when you build another bridge over the top and sometimes you just have to kill the whole branch you've been working on because adding a f*ing overhead sign collapsed seven other things and no matter what you try, you can't undo whatever it was that collapsed. I swear, one day we're going to find that someone accidentally nuked twelve routes six months ago and there's nothing anyone can do about it any more.
Edit: Oops replying to wrong person sorry.
