6 ms·

I have a strong suspicion that heavy handed enforcement of DRY (Don't Repeat Yourself) has lead to large codebases containing far too many abstractions in a foo

I have a strong suspicion that heavy handed enforcement of DRY (Don't Repeat Yourself) has lead to large codebases containing far too many abstractions in a foolish attempt to literally never repeat yourself. DRY can be a useful guideline but please don't enforce absolute, strict adherence. Sometimes a little duplication is okay and helps avoid complex, inflexible abstractions.

hliyan 8y ago
Also quoted as: "Duplication is better than the wrong abstraction"
- chrischattin 8y ago
  I'm a huge proponent of this concept. The goal is to be able to build and iterate as fast as possible. Most of this is achieved when new folks can step in and understand the code right away. Needless abstraction slows this down and makes the app more brittle to changes in response to customer/client inputs. Sandi Metz had an awesome presentation about this during a Rails Conf. "Duplication is far cheaper than wrong abstraction" https://www.youtube.com/watch?v=8bZh5LMaSmE https://www.youtube.com/watch?v=8bZh5LMaSmE Her blog talking more about the assertion: https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...
B-Con 8y ago
This is one of the idioms of Go I liked. "It's OK to repeat the same 3 lines of code." My thought process has always been: If there is a common piece of functionality to be shared, then refactor. If it just happens to be the same, maybe leave it.
- rabidrat 8y ago
  OTOH, when you're repeating the same 3 lines of code over and over, refactor so it can fit in one line of code. This is one of my big peeves with Go; in C at least I can make a RETURN_ERR macro.
- lelf 8y ago
  > It's OK to repeat the same 3 lines of code … 2–3 times. Not ok to repeat them 1000 times.
- ummonk 8y ago
  No, Go repeats the same 3 lines of code millions of times that you should never really have to do. There is no reason you should have to constantly throw in err != nil boilerplate when other languages have Optionals that make this automatic (and typechecked too). Likewise with for loops that could be done much more simply with proper maps and reduces.
ummonk 8y ago
My rule of thumb is always "which version is easier to understand and verify for a code reviewer?" Sometimes doing DRY means you've nicely separated out and encapsulated the common code that can be checked just once in isolation. Sometimes doing DRY means you end up with a complex abstraction that is hard to understand on its own.
jerf 8y ago
I agree, but I also think that you can harmonize DRY and "Don't abstract everything" by observing that repetition is a higher bar than it may first appear. A common DRY failure is when you abstract one function, then you find another place you can put it if you just add one more parameter, then you find that if you add two more parameters it fits here and here, and repeat until you've got a 12-parameter monstrosity loaded down with if statements and conditionals and block of code whose sole purpose is to preprocess the optional arguments into something the rest of the code will take... but what got you there still isn't the DRY principle, but that the repetition was actually never there in the first place. In the worst case you can end up with two or more things that should actually be entirely separated functions. I've personally done that once myself; tore one of these functions up into two functions literally by copying and pasting the lines of the original into the two new functions... and there was virtually no line that went into both the new ones. Post simplification the sum of the two new functions was about half the length of the original. And it wasn't anybody's "fault"... it has just grown that way, one commit at a time, over dozens of commits. DRY is still really important, but there's a lot of complexity/wisdom in what the true meaning of "repeat" is.

hliyan 8y ago

Also quoted as: "Duplication is better than the wrong abstraction"

chrischattin 8y ago
I'm a huge proponent of this concept. The goal is to be able to build and iterate as fast as possible. Most of this is achieved when new folks can step in and understand the code right away. Needless abstraction slows this down and makes the app more brittle to changes in response to customer/client inputs. Sandi Metz had an awesome presentation about this during a Rails Conf. "Duplication is far cheaper than wrong abstraction" https://www.youtube.com/watch?v=8bZh5LMaSmE https://www.youtube.com/watch?v=8bZh5LMaSmE Her blog talking more about the assertion: https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...

B-Con 8y ago

This is one of the idioms of Go I liked. "It's OK to repeat the same 3 lines of code." My thought process has always been: If there is a common piece of functionality to be shared, then refactor. If it just happens to be the same, maybe leave it.

rabidrat 8y ago
OTOH, when you're repeating the same 3 lines of code over and over, refactor so it can fit in one line of code. This is one of my big peeves with Go; in C at least I can make a RETURN_ERR macro.
lelf 8y ago
> It's OK to repeat the same 3 lines of code … 2–3 times. Not ok to repeat them 1000 times.
ummonk 8y ago
No, Go repeats the same 3 lines of code millions of times that you should never really have to do. There is no reason you should have to constantly throw in err != nil boilerplate when other languages have Optionals that make this automatic (and typechecked too). Likewise with for loops that could be done much more simply with proper maps and reduces.

ummonk 8y ago

My rule of thumb is always "which version is easier to understand and verify for a code reviewer?" Sometimes doing DRY means you've nicely separated out and encapsulated the common code that can be checked just once in isolation. Sometimes doing DRY means you end up with a complex abstraction that is hard to understand on its own.

jerf 8y ago

I agree, but I also think that you can harmonize DRY and "Don't abstract everything" by observing that repetition is a higher bar than it may first appear. A common DRY failure is when you abstract one function, then you find another place you can put it if you just add one more parameter, then you find that if you add two more parameters it fits here and here, and repeat until you've got a 12-parameter monstrosity loaded down with if statements and conditionals and block of code whose sole purpose is to preprocess the optional arguments into something the rest of the code will take... but what got you there still isn't the DRY principle, but that the repetition was actually never there in the first place. In the worst case you can end up with two or more things that should actually be entirely separated functions. I've personally done that once myself; tore one of these functions up into two functions literally by copying and pasting the lines of the original into the two new functions... and there was virtually no line that went into both the new ones. Post simplification the sum of the two new functions was about half the length of the original. And it wasn't anybody's "fault"... it has just grown that way, one commit at a time, over dozens of commits. DRY is still really important, but there's a lot of complexity/wisdom in what the true meaning of "repeat" is.