5 ms·

Yeah, obsession with DRY to the detriment of readability and maintainability does happen. If you need to write another script like the one you wrote yesterday (

Yeah, obsession with DRY to the detriment of readability and maintainability does happen. If you need to write another script like the one you wrote yesterday (but slightly different, and you don't know exactly how different), then starting with a copy&paste is a valid strategy. As you go on you will realize the common points of both scripts, and then you can DRY them both. Or not, if the common parts are too few to bother. Creating complex class hierarchies to "promote reuse" before there even is a case for reuse could be seen as premature optimization or YAGNI. On the flip side, in my experience, people with certain amount of years under their belts tend to treat all those principles in a way they should be, ie. as inspiration instead of as law.

__turbobrew__ 5y ago
A faulty/clumsy abstraction is worse than duplication.
- randomswede 5y ago
  And writing your abstraction before you have two or three different uses for it can often make it clumsy and/or faulty.
lambdaba 5y ago
This is something I've seen described as "optimizing for deletion" which is the only way to have true modularity.
- drittich 5y ago
  Yes! And deleting large amounts of code from a massive tightly-coupled monolith is a great way to learn that first-hand. I like to say that you learn a lot more from dealing with a legacy monolith than you do by implementing the latest clean patterns. It eliminates a lot of cargo-cult mentality and lets you really see what patterns make the difference.
ukoki 5y ago
My personal pet-peeve is when the obsession with DRY carries over to testing. Testing is not the place for DRY. Reading a test should be like reading a recipe: do A then do B, then do C, then expect result X. When you start abstracting the setup to the nth degree it becomes much harder to understand the test because you have to click around the code to following the abstractions like a trail of bread crumbs, when really what you want is for the stack trace to say "error on line 123" and the cause to easily found near line 123. Tests shouldn't be dry, they should be wet.
- KronisLV 5y ago
  This might be a reference to WET (write everything twice): https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33 https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-ev...
- avl999 5y ago
  It's a trade off for sure. I have seen people write test code with no regards to DRY and it results in tests that are hundreds of lines of setup trying to wire up the inputs and the expectations when a little bit of thought to remove all that repetitive code would go a long way in making the tests readable. I do agree that there doesn't need to be obsession with DRY when it comes to writing tests (esp when you are bouncing around multiple functions and files just to understand the testcase) but completely abandoning it either isn't great either.
  - taraskuzyk 5y ago
    Usually hunderds of lines of set up code point out the issue in the code itself -it's usually a smell of a god object/function that has too many responsibilities
- jgalentine007 5y ago
  I've run into exactly this, where each developer has their own test setup abstraction and attempt at automation. Difficult to add your own tests and difficult to fix theirs. It's maddening.
KronisLV 5y ago
A sensible suggestion i've found in regards to code duplication and DRY is the rule of three: https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra... If you run into the same code three times, that's when you consider refactoring. Of course, in practice it can be ignored like any rule as long as you keep the ideas behind it in mind (small amounts of duplication are usually manageable). Sometimes you have a shared context which might indeed use the same code and you'll want to apply DRY sooner, whereas other times you'll have code that is the same only incidentally, but is a part of two or more different contexts which may evolve independently. Edit: If only we had tooling on top of Git to give us hints about how the codebase has evolved over time, like: "Hey, this file is 84% similar to this one other file, which was added under ISSUE-2415 3 years ago by $PERSON for $PURPOSE. Click here to see the current diff between these files and how they've evolved over time." The current workflows around git blame feel lacking, especially if you are ever dealing with files that have been deleted (e.g. the "origin" for the current file was actually a different file that was deleted way back for another reason that you won't know about now without digging through the Git history for thousands of commits).

__turbobrew__ 5y ago

A faulty/clumsy abstraction is worse than duplication.

randomswede 5y ago
And writing your abstraction before you have two or three different uses for it can often make it clumsy and/or faulty.

lambdaba 5y ago

This is something I've seen described as "optimizing for deletion" which is the only way to have true modularity.

drittich 5y ago
Yes! And deleting large amounts of code from a massive tightly-coupled monolith is a great way to learn that first-hand. I like to say that you learn a lot more from dealing with a legacy monolith than you do by implementing the latest clean patterns. It eliminates a lot of cargo-cult mentality and lets you really see what patterns make the difference.

ukoki 5y ago

My personal pet-peeve is when the obsession with DRY carries over to testing. Testing is not the place for DRY. Reading a test should be like reading a recipe: do A then do B, then do C, then expect result X. When you start abstracting the setup to the nth degree it becomes much harder to understand the test because you have to click around the code to following the abstractions like a trail of bread crumbs, when really what you want is for the stack trace to say "error on line 123" and the cause to easily found near line 123. Tests shouldn't be dry, they should be wet.

KronisLV 5y ago
This might be a reference to WET (write everything twice): https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33 https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-ev...
avl999 5y ago
It's a trade off for sure. I have seen people write test code with no regards to DRY and it results in tests that are hundreds of lines of setup trying to wire up the inputs and the expectations when a little bit of thought to remove all that repetitive code would go a long way in making the tests readable. I do agree that there doesn't need to be obsession with DRY when it comes to writing tests (esp when you are bouncing around multiple functions and files just to understand the testcase) but completely abandoning it either isn't great either.
- taraskuzyk 5y ago
  Usually hunderds of lines of set up code point out the issue in the code itself -it's usually a smell of a god object/function that has too many responsibilities
jgalentine007 5y ago
I've run into exactly this, where each developer has their own test setup abstraction and attempt at automation. Difficult to add your own tests and difficult to fix theirs. It's maddening.

KronisLV 5y ago

A sensible suggestion i've found in regards to code duplication and DRY is the rule of three: https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra... If you run into the same code three times, that's when you consider refactoring. Of course, in practice it can be ignored like any rule as long as you keep the ideas behind it in mind (small amounts of duplication are usually manageable). Sometimes you have a shared context which might indeed use the same code and you'll want to apply DRY sooner, whereas other times you'll have code that is the same only incidentally, but is a part of two or more different contexts which may evolve independently. Edit: If only we had tooling on top of Git to give us hints about how the codebase has evolved over time, like: "Hey, this file is 84% similar to this one other file, which was added under ISSUE-2415 3 years ago by $PERSON for $PURPOSE. Click here to see the current diff between these files and how they've evolved over time." The current workflows around git blame feel lacking, especially if you are ever dealing with files that have been deleted (e.g. the "origin" for the current file was actually a different file that was deleted way back for another reason that you won't know about now without digging through the Git history for thousands of commits).