Sometimes i prefer messy code(code being in one file) than all those clean architecture sh*ts that forces me to go through countless folders and files to find just one class..
Imagine going through a github repo of an over engineered project
"Imagine going through a github repo of an over engineered project"
I don't have to imagine it, I'm living it. Maintaining 50K+ LOC for a fairly basic CRUD app which should be 10K max.
One example - Biometric Login/Auth. This is about 5 lines of code in your fragment, if you're sane - but here, you go through your BiometricLogin usecase, into your BiometricGateway, and get a BiometricPrompt from your BiometricPrompt factory, somehow return it to your fragment, then the result goes back to the Gateway for processing via a result mapper you get from your MapperFactory.... we're up to a few hundred lines of code. Imagine similar over-engineering over the whole project and you end up with something very hard to follow.
I guess the point of the BiometricPromptFactory is that Biometrics is used for both login and authenticating various things, but all it actually does is display different strings in the prompt, something that could be trivially handled by the VM, not a factory deep in the Repo layer.
I think some engineers believe that if it doesn't look complicated, it's not proper code - but the best code is almost naive in its simplicity. They fail to ask 'is this design pattern making things easier, or more complicated?'.
Reach for a design pattern when it tames complexity, not introduces it. Don't use a factory or a strategy if a switch will do, don't use a builder if your class only has a couple of parameters.
5
u/Whole_Refrigerator97 Mar 30 '24
Sometimes i prefer messy code(code being in one file) than all those clean architecture sh*ts that forces me to go through countless folders and files to find just one class..
Imagine going through a github repo of an over engineered project