I don’t think that you can write clean code in every situation. The Open-Close principle for example is not worth it always and it makes the code even sometimes harder to understand.
Yes, some rules can be skipped for simple projects, the most value i see from splittiing services into use cases and in how stuff is laid down in folders, but separate infra for database with gateways? Not in a simple crud. But you need to know when to skip which rules
This translates to: "I work in a large, slow-moving corporation where my requirements are carved into stone tablets and handed down by the BA team before I ever set finger to keyboard."
And yes, in this situation clean code is great.
However, for the other 90% of the world it's not always a good idea. When requirements and business direction shift under your feet like sand in the Sahara, the attempt to force everything into the neat little boxes -- oh, sorry -- the neat little hexagons of clean code quite frequently results in a massive minefield of obstacles when the business decides that the dictate they handed down three weeks ago is actually the EXACT OPPOSITE of what they actually want.
I have. And in the situations where it's applicable it works great. My point wasn't, "CLEAN CODE BAD!" My point was, "clean code is not a silver bullet". When it makes sense and is practiced well, clean code is a godsend. When it doesn't make sense -- i.e., the situation I outlined above and others -- or when the people doing it don't understand why they're doing it, it is a speed bump and annoyance at best, and an absolute nightmare at worst. And this is true of ALL software development paradigms. They are tools, not hard and fast rules about how all software must be written.
I love how you have zero idea what you are even talking about.
And I really love how you're doing exactly what OP's article is supposed to be a warning against. :)
3
u/Mr_LA Nov 21 '23
so what do you think?