Our original backend codebase used so-called "clean architecture" and really put the Java back in JavaScript (actually TypeScript, but hopefully you get my meaning).

For every endpoint I want to create, our design needs at least two classes that are basically callable singletons. If my understanding doesn't fail me, it could have been simple old functions... I think?

"Senior" engineers will always try to reinvent the wheel to try to make themselves stand out.

Clean Architecture makes a lot of sense when you have a lot of different IO (like in a backend): different DBs and APIs (REST/WS/...), executing UseCases via HTTP/CLI/Events and so on. Clean Architecture is awesome for unit and integration tests. But I don't think it all that useful for FE: in FP, you already have functional architecture; which already separates side effects and pure-functions ("mutable shell" and "core-code"). So when you say, it "put the Java in JavaScript" that made me lol irl what a nightmare 😄

@SuspiciousBug I just looked at my commits in the PR I opened, I did in like 130 lines what I could've done in maybe 10 or 20

@nururururu
Clean makes sense if you want your code to be tested using mock classes. Or in a framework areas.

It does have its uses when you want robust unit tests. And increasing your loc count.

@magicMirror oh, yes, our LOC count is off the charts, and creating simple endpoints feels like a huge chore. We have something of a "clean architecture", but very few tests. I'm going to change that as I implement new features, and I'll learn as much as I can from the fellow backend developer who's much more experienced than me.

@nururururu
If you don't have tests... Whats the point of clean arch?
It just slows you, and increases the complexity of the project with zero benefit.

Btw - if used correctly, it can increase code reuse. But only if the devs *know* the codebase, and actually reuse the relevant parts.

Run

@magicMirror ask my boss lmao

But at least the code looks like what the people who know more about tests than me call "testable", so I guess adding tests will be smoother

The new/more experienced dev is experienced with them and is guiding me through structuring and adding tests for new features we add, I also added some as I refactored some older things

@nururururu
I once even used "testable" to try and convince my team to actually write our code in a way that we can *test*. It was a data to mongo pipeline - without tests other then "worked for me once yesterday! let ship!". It had 20-30 modules that got random data, and added to 5 mongo collections.

🤡 TL was sure I wrote tests - when I was talking about how to refactor, and decouple so tests could potentially cover 99% of the modules. Tests were not written. Modules got refactored every two years after enough bugs (and client attention). But the 🤡 had a point: "testable" without tests makes zero sense. It will just increases the workload.

uncle bob is the biggest disgrace to happen to the field of software engineering. A monkey typing on a keyboard randomly can produce a better architecture.