[quickthrower2]

The best code is the code that doesn’t need to be read at all. This takes a lot of skill in abstraction.

For example code a “user data cache” with lots of user concerns and people will be reading that code a lot.

Code a “generic cache” and test the hell out of it and it’ll never need to be read (or rarely)

There will need to be code that deals with users but it can interact with the cache so where business logic ends and caching begins is obvious.

Then repeat: how can you split the user code up into generic concepts? Users vs. roles vs. credentials?

[nathias]

Of course it will have to be read, what makes you think you can guess what people will have to read? This seems such an anti-pattern, instead of writing readable code that lives inside the domain where its used, you make an unnecessary abstraction. This is exactly how redundant complexity gets made and you wind up with 16 abstraction layers where each is used just once and a completely unreadable mess.

[quickthrower2]

The advantage of good abstracting is you can unit test one layer and make it super solid, then build the next layer with less mental load.

I am not advocating making “unnecessary” abstractions.

I’m not even advocating abstracting from the get go: sometimes you need to see the messy to appreciate the abstracted.

This is modulo all common sense trade offs!

[nathias]

Making things into units and making things in generalities is something very different. There is no such thing as a new introduction of a generality that would lessen the mental load in itself, it is both a source of bugs and an obstacle to reading but of course sometimes the tradeoffs are worth it. It just that your solution to reading seems to imply that generalization as such is helpful, and I think its the main cause of redundant complexity.

[derangedHorse]

I think you're too stuck remembering the bad implementations of generality to understand what the original poster is saying. Something like a cache is general and most likely will need to be used in multiple places. If I have a user cache and an application cache, it wouldn't hurt to build both off a general cache. That way I don't have to understand two different cache implementations that are supposed to do the same thing. Now when a new cache implementation is made in a particular domain, there will be no need to review the code that does the caching since developers should already be familiar from working with it in the past. I don't see how it could be "both a source of bugs and an obstacle to reading" unless done improperly.

[verinus]

this.

While it is important to separate concerns where applicable (might be user related functionality and caching) generalization most of the time just adds complexity.

[geitir]

Good insight