19

Lets create a library.

Lets use that library in a project.

Lets wrap the library call in a wrapper functione to remove duplicate code.

Lets add an overloaded wrapper call that wraps the wrapper call that calls the library to partially undo the duplicate code removal.

Lets add another overloaded wrapper call that wraps the wrapper call that wraps the wrapper call that calls the library to partially undo the duplicate code removal.

How I love it. Not.

Sometimes redundancy makes sense, especially when it are two lines which make it obvious whats going on vs a single line that leads to a fuckton of overloaded wrapper functions.

Sheeesh.

Today in "code monkeys deserve divine punishment".

Another funny thing is creating a Helper class for Junit 5 tests, making it instantiable and adding to it all kinds of shit like testcontainer creation, applications instantiation, mocks, ....

... Then " crying " why the tests are so slow.

Yeah. Logic. Isolation of concerns, each test should be a stand alone complex.

But that would lead to redundancy... Oh no.

Better to create a global state god object.

Some devs... Really amaze me, especially when they argument in ways that makes one really wonder whether they are serious or just brain dead.

Comments
  • 0
  • 1
    @jestdotty

    So they create an unmaintanable mess?

    DevRant never ceases to amaze me.
  • 5
    > But that would lead to redundancy... Oh no

    Ironically all the noobs who blindly apply the "clean code" and "dry" patterns everywhere have the worst and least maintainable/debuggable code
    A bit of redundancy that simplifies it is 100x better

    Seen someone refactor a 2-liner into a fucking 30 line monstrosity with enums and hash maps and loops etc just to avoid duplication and to make it "extendable" in the future (for cases that will never happen)
  • 0
    @devRancid totally agree, you should pivot the code only when the necessity emerges
Add Comment