What's the point of abstraction layers if you're riddling all the code with

if (AbstractionLayer.SomeType instanceof ImplemantationLayer.SomeTypeIml1) {
// do stuff
} else if (AbstractionLayer.SomeType instanceof ImplemantationLayer.SomeTypeIml2) {
// do stuff
} else if (AbstractionLayer.SomeType instanceof ImplemantationLayer.SomeTypeIml3) {
// do stuff
} else if (AbstractionLayer.SomeType instanceof ImplemantationLayer.SomeTypeIml4) {
// do stuff
}

???

Seriously.. Guys. Am I missing some point here?

Two actual lines of code I stumbled upon...

static ArchiveAbstract ARCHIVE_TRUE = new ArchiveTrue();
static ArchiveAbstract ARCHIVE_FALSE = new ArchiveFalse();

Ok you might think, what is going on? Searching for it's usage yields exactly a single case:

if(someVar instanceof ArchiveTrue ? true : false)

So someone managed to introduce 3 new classes... instead of using a simple boolean.
(╯°□°）╯︵ ┻━┻

Help. I'm drowning in spaghetti code

I've been working at a working student (15 hours/ week) at a local software company for about a month now... and with everything I learned at college I'm kind of getting eye cancer here.
We still use SVN
We don't have any coding guidelines. No checkstyle, no overview over the program. When I started there I was just giving a ticket and they said good luck.
We just have some basic RCPTT Tests inside Eclipse and most of Themen don't work in the trunk because the gui got changed...
At least we have a ticket system but it doesn't get used by most of the working students.
I found 10 other bugs while reproducing and trying to fix 1 bug.
And I've never seen Java raped so badly. Today I saw a line that started with 6 brackets because whoever wrote it wanted to cast like there was no tomorrow. I see more instanceof in one day than in my whole devlife before.
The only thing we have is two normal employees that review our code before we are allowed to commit it into the trunk.
So yeah... I'm drowning in spaghetti-code.

I will die younger because of node packages

It's like quantum mechanics, so undeterministic, even with yarn.lock, I had this meeting to demo software and I was ready for 2 min past the meeting time, having worked nearly all night to save monorepo yarn workspaces issues where some module has peer dependency it shouldn't have and some other module installed a newer version of a package which broke another module with another version of the same package, one module checks if it's got an instanceof another package, but it returns false because it's another version of the same package that created it so X !== X.

I nearly had a nervous breakdown and my node modules won't fix when I remove all node_modules in the yarn+lerna monorepo and reinstall from scratch... it's like seeing ghosts with these errors all works for months and then a butterfly splashes its wings near 1 node module and the entire app fails apart.

:'''(

PSA to all non-software engineers:

Hacker instanceof SoftwareEngineer && !(SoftwareEngineer instanceof Hacker)

Please, next time I say I am a software engineer, do not assume I can magically hack the FBI nor can I get those nude pics off your friend's phone.

Holy Mother of casts.
Just stumbled across a line that started with (((((( because it has so many casts in it...
That's why you don't use instanceof kids.

So far in my (albeit short) career, I struggle to find people who know what polymorphism is, and how to use it. SOLID is a big unknown too.

It's always
if(this instanceof A) {}
else if(this instanceof B) {}

Allright, so now I have to extend a brand new application, released to LIVE just weeks ago by devs at out client's company. This application is advertised as very well structured, easy to work on, µservices-based masterpiece.

Well either I lack a loooot of xp to understand the "µservices", "easy to work on" and "well structured" parts in this app or I'm really underpaid to deal with all of this...

- part of business logic is implemented in controllers. Good luck reusing it w/o bringing up all the mappings...
- magic numbers every-fucking-where... I tried adding some constants to make it at least a tiny bit more configurable... I was yelled at by the lead dev of the app for this later.
- crud-only subservices (wrapped by facade-like services, but still.. CRUD (sub)services? Then what's a repository for...?). As a result devs didn't have a place where they could write business logic. So business logic is now in: controllers (also responsible for mapping), helpers (also application layer; used by controllers; using services).
- no transactions wrapping several actions, like removing item from CURRENT table first and then recreating it in HISTORY table. No rollback/recovery mechanism in service layers if things go South.
- no clean-code. One can easily find lines (streams) 400+ cols long.
- no encapsulation. Object fields are accessed directly
- Controllers, once get result from Services (i.e. Facade), must have a tree of: if (result instanceof SomeService.SomeSubservice1.Item1) {...} else if (result instanceof SomeService.SomeSubservice2.Item4) {...} etc. to build a proper DTO. IMO this is not a way to make abstraction - application should NOT know services' internals.
- µservices use different tables (hats off for this one!) but their records must have the same IDs. E.g. if I order a burger and coke - there are 2 order items in my order #442. When I make a payment I create an invoice which must have an id #442. And I'm talking about data layer, not service or application (dto)! Shouldn't µservices be loosely coupled and be able to serve independently...? What happens if I reuse InvoiceµService in some other app?

What are your thoughts?