As in everything else, it boils down to an issue of balance.
For large C++ codebases at work, this leads to coding standards like:
- Don't introduce typedefs referencing other typedefs in public API, especially when the typedefs and the API that uses them are in different files. Having to look in more than half a dozen different files just to understand the signature of a function is actively reader-hostile.
We have a ton of conventions similar to this that help to make the code significantly more pleasant to read. It turns out that we still have quite a few useful abstractions, but they tend to be fairly large compared to most codebases I've worked with previously.
My team inherited a code base that wasn't really legacy - maybe two years old - with a very simple business logic: Collect data from one REST service, save it in a "cache" database and answer to requests from another one. Seems completely simple, and the code wasn't awful, either. However, there was no abstraction, no layers, nothing: The REST controllers knew exactly what the DB looked like and contained a large part of the collection logic. There was a client for the collection, but it was very low level and exposed everything. Additional domain logic was smeared over five to ten levels of hierarchy.
In the end, each apparantely simple feature we had to add took days instead of hours because we had to touch so much code. The principle of locality was completely absent. In the end, we rewrote large parts of it so that you don't have to change the REST controller anymore if the DB schema changes.
My personal lesson was that you should always have some abstraction, even if the service's task is so simple. Things will change, and you must be prepared for that. If every part of your code knows all the other parts, you're doing it wrong. Have clear interfaces and boundaries (and models) so that changes can be localized. Of course, that doesn't mean that you should implement something like: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... .