3 ms·

I sometimes use term "mid-level engineer syndrome", for "too many levels of abstraction in the codebase". It is very common in my experience. And untangling it'

I sometimes use term "mid-level engineer syndrome", for "too many levels of abstraction in the codebase". It is very common in my experience. And untangling it's usually harder then extracting common stuff from "dumb" code. I usually don't DRY things up until three repetitions. And in test code - try to not DRY at all, copypaste is a friend of readable and mantainable specs.

CTmystery 4y ago
You're almost there, IMO. This internet stranger encourages you to ditch the rule of DRYing based on the number of repetitions at all, and instead think of DRYing based on what deserves to change to together. Sometimes a single repetition in code deserves to be DRY. Sometimes 10 repetitions don't deserve to be DRY.
- ryathal 4y ago
  Isn't that playing a little loose with definitions? if you have 10 "repetitions" that don't need to change simultaneously they aren't really repetitions in the first place. Just because a dumb analyzer says you have a 10 line block of identical code in 10 places doesn't mean it's actually identical.
  - sirmarksalot 4y ago
    You're restating the article's point. Naive DRY says make the dumb analyzer happy by abstracting out the coincidental similarities. If you work in a place that recognizes that this can be a red herring, then great, but a lot of developers and teams don't make room for that nuance. That is what the article is arguing against.
deleted 4y ago
[deleted]
scambier 4y ago
I have colleagues that take DRY to an extreme when it comes to tests. There are so many levels of abstractions that it's incomprehensible. Tests should be clear and readable, you shouldn't have to dig code to understand _what_ a test is doing.
- michaelcampbell 4y ago
  Tests in particular SHOULDN'T be DRY, IMO. They need to be very much independently modifiable quickly; they're meant to be quirky end-runs around your bespoke, artisinal architecture to get at all the interesting bits. Repetition there is fine.
  - baobabKoodaa 4y ago
    A downside of this approach is that sometimes when you make a small implementation change, you need to rewrite 50 unit tests.
  - bcrosby95 4y ago
    I dunno. I think a few helper methods helps a lot in tests - like if you have a common operation in the setup portion. I don't think the code needs to be super abstract, but it shouldn't all be hand typed out.
kosmotaur 4y ago
> copypaste is a friend of readable and mantainable specs Another generic statement: copypaste (as I understand you mean the opposite of extracting common code) between specs goes against single responsibility. Rather than `setupUser()` you open a connection, create a user fixture, write it to the db, and then paste that across all the specs. Doing quite a lot. I can imagine a spec with let's say 20 cases. Arrangement of each takes about 6 lines to load something, change some state the test subject depends on, the usual stuff, like in the above example. A week from now, 10 cases need an extra line of setup, which you dutifully paste across the specs which require them. You put it somewhere in the middle, as it needs an id from the first step of 6. This happens once or twice. The commonality of the original 6 copy pasted all over the place is hashed up, interspersed with calls specific to each test. The linking factor between those 6 lines is now obscured and requiring careful analysis if only those 6 need to change. This can be avoided if you extract the common bits out early on. Rule of three is your friend if you don't want to rush it.
WorldMaker 4y ago
I'm a big proponent for the "rule of [at least] three" for building DRY abstractions: once is YAGNI (you aren't going to need it), twice is coincidence, three is finally a pattern emerging.

CTmystery 4y ago

You're almost there, IMO. This internet stranger encourages you to ditch the rule of DRYing based on the number of repetitions at all, and instead think of DRYing based on what deserves to change to together. Sometimes a single repetition in code deserves to be DRY. Sometimes 10 repetitions don't deserve to be DRY.

ryathal 4y ago
Isn't that playing a little loose with definitions? if you have 10 "repetitions" that don't need to change simultaneously they aren't really repetitions in the first place. Just because a dumb analyzer says you have a 10 line block of identical code in 10 places doesn't mean it's actually identical.
- sirmarksalot 4y ago
  You're restating the article's point. Naive DRY says make the dumb analyzer happy by abstracting out the coincidental similarities. If you work in a place that recognizes that this can be a red herring, then great, but a lot of developers and teams don't make room for that nuance. That is what the article is arguing against.

deleted 4y ago

[deleted]

scambier 4y ago

I have colleagues that take DRY to an extreme when it comes to tests. There are so many levels of abstractions that it's incomprehensible. Tests should be clear and readable, you shouldn't have to dig code to understand _what_ a test is doing.

michaelcampbell 4y ago
Tests in particular SHOULDN'T be DRY, IMO. They need to be very much independently modifiable quickly; they're meant to be quirky end-runs around your bespoke, artisinal architecture to get at all the interesting bits. Repetition there is fine.
- baobabKoodaa 4y ago
  A downside of this approach is that sometimes when you make a small implementation change, you need to rewrite 50 unit tests.
- bcrosby95 4y ago
  I dunno. I think a few helper methods helps a lot in tests - like if you have a common operation in the setup portion. I don't think the code needs to be super abstract, but it shouldn't all be hand typed out.

kosmotaur 4y ago

> copypaste is a friend of readable and mantainable specs Another generic statement: copypaste (as I understand you mean the opposite of extracting common code) between specs goes against single responsibility. Rather than `setupUser()` you open a connection, create a user fixture, write it to the db, and then paste that across all the specs. Doing quite a lot. I can imagine a spec with let's say 20 cases. Arrangement of each takes about 6 lines to load something, change some state the test subject depends on, the usual stuff, like in the above example. A week from now, 10 cases need an extra line of setup, which you dutifully paste across the specs which require them. You put it somewhere in the middle, as it needs an id from the first step of 6. This happens once or twice. The commonality of the original 6 copy pasted all over the place is hashed up, interspersed with calls specific to each test. The linking factor between those 6 lines is now obscured and requiring careful analysis if only those 6 need to change. This can be avoided if you extract the common bits out early on. Rule of three is your friend if you don't want to rush it.

WorldMaker 4y ago

I'm a big proponent for the "rule of [at least] three" for building DRY abstractions: once is YAGNI (you aren't going to need it), twice is coincidence, three is finally a pattern emerging.