36 ms·
Just because the number of abstraction layers can be reduced doesn't mean they need to be. You might gain back some CPU cycles, some milliseconds of execution t
by mttpgn 2y ago
Just because the number of abstraction layers can be reduced doesn't mean they need to be. You might gain back some CPU cycles, some milliseconds of execution time. But the tradeoffs of maintainability, legibility, and developer quality-of-life may, in the long run, reintroduce abstraction layers of some other type back into the overall SDLC.
- ben_w 2y ago> But the tradeoffs of maintainability, legibility, and developer quality-of-life Are in fact the things I think have become worse from the abstractions. Well, the recent abstractions. I like the ones that were widespread until about 2018 or so.
- richardwhiuk 2y agoNone of the abstractions above are new in the last 5 years.
- ben_w 2y agoI was thinking about this before learning about any of the ones in the post, if that's what you're saying.
- bitterblotter 2y agoIm curious. Can you expand / give examples?
- ben_w 2y agoThe VIPER pattern is my biggest bug-bear (but older than I realised: I didn't see it until recently, and it still seems to only be described on the German Wikipedia and not the English one), which seems to come with more glue code than business logic. • https://www.mutualmobile.com/blog/meet-viper-mutual-mobiles-application-of-clean-architecture-for-ios-apps https://www.mutualmobile.com/blog/meet-viper-mutual-mobiles-... • https://de.wikipedia.org/wiki/VIPER_(Entwurfsmuster) https://de.wikipedia.org/wiki/VIPER_(Entwurfsmuster) I also get annoyed by HTTP 200 responses containing JSON which says "server error", and web pages which use Javascript to re-implement links, image loading, and scrolling — all of which are examples of a high-level abstraction reinventing (badly) something that was already present in a lower-level of abstraction.