Abstractions, repetition and discovery (2015)
beyond-code.com
beyond-code.com
IMO, the main issue with DRY and other simplistic guidelines like the "rule of three" is that it lacks nuance regarding the "why" and the "what" of abstractions.
Putting repeated code in a single code or breaking up classes or methods into multiple due to the number of lines doesn't make for a good abstraction, sometimes it's just an indirection that's not really an abstraction.
I find that the concept of "abstraction levels" is a good guideline as to where to separate the code. The example given here is nice: have the business-related configuration in one level with the rows, and rendering code itself (that knows nothing about business part) in a deeper layer.
Rarely done, instead people just cargo cult on, do it for consistency even if they don't like it, or are too lazy or afraid to tear something down again.
One of my biggest peeves right here. In particular, Ruby code seems to attract this. It’s usually more annoying to read the chain of 30 method calls than it is to read the 60 lines of sequential code.