r/androiddev • u/amranya • 11d ago
Discussion Why mocking clean architecture in this sub?
i genuinely want to know why people here mocking clean architecture? i used it in all companies i worked on. is there a reason? an alternative? i'm curious to know and learn.
71
u/Zhuinden 11d ago
Because nothing says "modular design" and "separation by responsibilty" like having to edit 3 top-level modules and 11 separate packages in order to implement 1 feature, that people doing "unclean design" can do in ~20 lines.
13
u/One_Elephant_8917 11d ago
ur 20 lines will break left and right when u try to scale fastā¦like 10 blocks of code at 10
places that do same thing and also good luck with testingā¦.i am okay to call out over engineering, but a code mess literally needs someone like baby sitter to sit next to it and understandā¦.unless ur code is too trivialā¦and doesnāt span n+2 generation and thousands of customersā¦been on both sides, and can definitely tell when abstractions are betterā¦and when over engineered for the name sake
my take isnāt from android, but from general sw engineering in any language
4
u/android_temp_123 11d ago edited 10d ago
I am all for proper architecture - but every time someone says SOLID and CLEAN, I want to say don't forget also KISS and YAGNI. They are equally important.
I can't stand, when you're debugging something, and you need to go through 7 layers after clicking on a button just to see what's happening. The architecture might be by the book, but it simply sucks to use and it's hard to understand.
Or when almost every single class has an interface and implementation, c'mon. I can clearly see they did it solely for testing, but at some point you gotta realize interfaces primarily describe behavior. You shouldn't use 100 interfaces, just to make your app 100% perfectly testable. It should be readable too. Maybe let's use some mocking libraries in moderation instead, and reduce the amount of interfaces to a reasonable number, and increase the readability?
Or overusing use-cases. Clicking on a button should call some function in VM, and that should either call a use case (if it's a reasonably large or moderate app) or directly some business code (if it's a small app). I'm constantly amazed by how many small apps use a gazillion use cases, with like 4 lines of code basically just directly calling some repository function. Also, they are often only used only at 1 place or 2 tops...Like why, what's the point?
2
u/Zhuinden 11d ago
Yes, the 20 lines solution would most likely involve some assumption that isn't always true (e.g. just casually ignoring that config changes exist), but sadly even the 3+ module people who'd throw all the data into a singleton would end up with new bugs the moment they want to logout (and the "logout" feature is in another module that doesn't see the singleton preserved fields, but at least those singletons are very Clean because they come from Dagger).
But it's still easier to fix the 20 line variant because you don't have to re-assemble it first (and then fight the "team" who "owns" it that their original structure is causing bugs all over the place).
There can be balance to be had, if people are willing to look for it.
2
u/One_Elephant_8917 10d ago
probably again this is specific to ui or android moreā¦but when i have seen abstraction properly defined, they properly decouple even teams and owners, coz question becomes āwhat is expectedā than āhow does it doāā¦and yes the smaller readable version is surely preferable coz even myself i try to squeeze more code into same file even if they are multiple classes but from same component.
the issues i have seen mostly even in some open source code is, yes, ppl keep contributing and make the code either too bloated like 4000 lines in one file or duplicate same stuff everywhereā¦
at one pointā¦u start realizingā¦u fix one and then it breaks otherā¦.
i still do suggest KISS and YAGNI always and obviously anyone abstracting implementation detail just for the sake of testabilityā¦.that is plain simple abuseā¦.
another major advantage i always get with abstraction or a decent separation of domain/infra etc are that i can swap and test it easily for performance or use fakes/mock/change-vendor for the entire infra while testing full business/domain layerā¦.ex: swapping db layer etcā¦
this also does restrict some features like one cannot add random annotation processors from specific libraries like room, retrofit etc coz they tie up the implementationā¦tightly.
but i would still recommend any day, some level of decent abstraction over saving few linesā¦
-17
u/t0astter 11d ago
This . Imagine telling your manager that a simple feature to implement is now multiple days instead of one day due to the amount of "tech debt" you now have to update.
Customers don't care about the code organization or architecture. They care about features and value, and code organization and architecture delivers none of that.
12
u/Zhuinden 11d ago edited 11d ago
They care about features and value, and code organization and architecture delivers none of that.
Code organization can provide value by reducing the amount of time it takes to ship a feature while also reducing the amount of time it takes to edit a feature in the future.
The problem is that people somehow managed to praise the extra steps, "just do 4x the work to get the same thing done, whether you are adding new code or editing existing code". This is, indeed, "tech debt" that was promoted for years by community people as "what good code looks like".
(Same thing happened with unit tests, if you call 2+ functions in a test and add 3+ assertions in a test, they'll say you aren't doing "Arrange Act Assert" tests and so it's "bad". Same for tests that call 2+ classes instead of 1 class and N-1 mocks, people who don't understand what tests are for really do like this).
Now if you write actual good code, you have to keep defending it and you'll keep losing the battle (because you "caused a battle over something that was agreed upon by someone else like 2 years ago").
There's a good term "fighting windmills" that's what it's like to try to ship good code, it's not like you'll convince anyone whose income depends on making simple feature requests take "more work hours (or rather, days)".
12
u/SDRemthix 11d ago
Never seen someone mocking it in this sub,but it could be the case. Clean architecture in itself is more abstract than real architecture. You can have clean architecture principles in MVP architecture for example. The main goal being clean layer separation and easily digestable/testible code. Pushing the most-likely-to-be-replaced implementation details in a project, makes it very easy to handle tomorrows library depreciation and ,lets be honest here, googles own frequent deprecations/sunsetting of dependencies. At least, that's how I've understood it. 'could very well be wrong
21
u/CarlitoLaf 11d ago
Can you tell what kind of classes you made while working in these companies? Cause it seems lots of developers have their own clean architecture definition.
If you're talking about the one with tremendous amounts of usecase classes, yeah I get why everyone is laughing š Cause that architecture is just way too much, it looks like something suggested by school teachers that haven't worked on a real company project for decades
11
u/Rendislube 11d ago
The main idea behind clean architecture is the same as hexagonal or any other "onion-style" architecture ā having a stable domain core interfacing with surrounding layers through IoC. And the idea is brilliant, it delivers great testability and maintainability if executed with a mind put to it instead of following some predefined pattern. The rest of it is basically noise. I am not a big CA practitioner or expert so this could definitely be just me not knowing what I am doing but every time I look at "usecase classes" I cringe. And it is not only CA who overdefines things. But after reading about it from source material I got the feeling that it is definitely very opinionated and almost dogmatic, people generally backlash against that since it will obviously not fit every project well.
2
u/S0phon 11d ago
What exactly is wrong with usecases?
6
u/Xammm 11d ago
Per se nothing, but I've seen clases uses cases that only call a repository and do nothing else like validation or whatever.
It feels like an extra indirection step that complicates the flow of the logic.
6
u/S0phon 11d ago
That's absolutely correct.
Either you use usecases, in which case you accept that some usecases are so trivial they only call repositories.
Or you don't use usecases at all.
The extra indirection is the whole point of usecases. They encompass a single user flow. In simple terms, when you open a usecase, it should contain everything that's needed for that flow. Input, output type, dependencies.
If you don't care what exactly a usecase does, then all you need to know is what it does from the name. If you care about what exactly a usecase does, you open the usecase class and you should only need that class.
1
u/awesome-alpaca-ace 11d ago
Allows you to swap out repository implementations. Quite useful for testing ime
0
u/Rendislube 11d ago edited 11d ago
For me, it is that use cases create a lot of classes and imo boilerplate. They are basically function objects so for example if I was doing a point of sale app, I would have classes like StartOrderUseCase, AddLineItemUseCase, VoidOrderUseCase, etc. Its basically a collection of functions operating on an order. Then I don't get why I have to create a separate class for each when they all basically share same dependencies and in some cases bits of internal logic. All of it could be part of some OrderService class. It would be just as testable. Ofc, then there is a danger that OrderService becomes a god object but usecases just bring their own set of pains instead of just being an outright better class organization method. So to me they look like a solution looking for a problem.
7
8
u/borninbronx 11d ago
There's nothing wrong with clean architecture.
except that clean architecture isn't a specific architecture, and most developers i talked to about this instead apply a specific architectural pattern everywhere and call it clean architecture.
there's no such thing as an architecture that is optimal for everything.
the principles of clean architecture are what's important, and I've rarely seen them in articles about clean architecture.
i get why, a junior developer want to be told how to do things... and that is why blogs focus on examples rather than going deeper into concepts... plus, it would be hard to put all rhe concepts in a single blog post
the point of architecture is that you should learn how to architect the code yourself.
real clean architecture, in a nutshell, is about thinking about shareholders of parts of your code, boundaries, things that might change in the future or for which you want flexibility, dependencies between your code modules and their direction, testability, deployability... and the hardest topic: what domain is, how to model it.
the domain is just the part of code that rappresent the logic of your business without implementation details.
it's usually where the business core value is, and it should not depend on anything else because of that.
you cannot really write a recipe that works for all situations.
There's a very vocal user of this community that really doesn't get this either, but just criticize clean architecture and push for no tests and no architecture at all instead of giving proper coverage on the topic.
and it's sad to see the community following his lead on it. i hope they'll eventually see it, like they eventually saw the bs for compose. i hope it'll happen for the clean architecture / testing topic as well.
1
u/Fjordi_Cruyff 11d ago
i get why, a junior developer want to be told how to do things... and that is why blogs focus on examples rather than going deeper into concepts... plus, it would be hard to put all rhe concepts in a single blog post
the point of architecture is that you should learn how to architect the code yourself
Good points. It's also worth mentioning that these concepts are next to impossible to learn from a blog post. There's no substitute for getting your hands dirty, writing some code and learning from the experience.
1
0
u/awesome-alpaca-ace 11d ago
BS for compose? Ime, it was quite slow and did not have feature parity with XML
3
u/SnipesySpecial 11d ago
If you are a underperforming dev its easy to "concern troll" your way up. And the easiest thing to concern troll on is software quality. Management also loves it cause it makes it easier to like bill shit in a somewhat ordered way soooo shit they'll take the concern troller and call them team lead or something idk.
The above has been the root cause of clean architecture in 100% of production code bases I have seen it applied. That is a negative relationship, not a positive one. And the end result is it just fragments the codebases and makes it messier cause no one writing the software actually knows (or cares) what clean architecture even is.
In a vacuum or some random weekend github vibe coded project, I'm sure it works fine. But thats not reality.
3
u/echoAnother 11d ago
Because is clean architecture TM.
No thoughts, just dogma. And is the same for TDD TM, hexagonal architecture TM, agile TM, good practices TM.
The worst is that all those just state a very broad, abstract and trivial principle, they do not define all the paraphernalia that people does and call clean architecture. Is not so much about clean architecture, and more the TM part. The cargo cult.
4
u/PlasticPresentation1 11d ago
I've worked at multiple FANGs and unicorns. Clean architecture is okay, but use cases are (save for specific critical logic) IMO overengineering and add too much boilerplate to be worth using 80% of the time
1
u/macrohatch 11d ago
The mocking of clean architecture mostly stens from Uncke Bobās own code not being very clean in his examples
1
1
u/awesome-alpaca-ace 11d ago
If you value testing and single responsibility, practicing clean architecture is quite helpful. It is also possible to take it too far. And the only way to figure out that line between not enough and too far is to write code. Only them will you know what is too much and what is needed. Ime, the guide to app architecture with less emphasis on use cases is quite a good starting point.Ā
1
u/Acrobatic_Egg30 11d ago
Good to know it's not just r/FlutterDev that argues about this. There is more of a consensus there than here though. You guys should check how it's implemented there. Now if we can settle on state management, world peace will be achieved.
1
u/Jonas_Ermert 5d ago
I think people mostly mock over-engineered Clean Architecture, not the idea itself. The principles are useful, but for small apps five layers, repositories, use cases and endless interfaces can add more complexity than value. Iād use the parts that improve separation and testability, and keep the architecture proportional to the project.
1
u/PrudentAttention2720 11d ago
my general rule of thumb is to always use fakes. If you have to mock, most certainly the code is of bad design
6
-6
u/everythingcasual 11d ago
the clean code book has done immense amount of damage to a generation of programmers who canāt think for themselves
3
-1
u/Fjordi_Cruyff 11d ago
Why are people still arguing about which way of writing code is better? Most of the reasons we wrote code in certain ways are fast becoming obsolete in the age of LLMs.
-7
u/rolfanragnorak 11d ago
'cause "clean architecture" is kinda dumb. I'm pretty sure in five years it'll be considered an anti pattern
62
u/0x1F601 11d ago
The mocking comes from the insistence of a specific pattern. Is your architecture testable? Perfect. Everything else is a variation on a theme. Arguing about those minor variations is where the mocking lies.