Great article! The only thing I have to say is that I'm one of those people who says that repeating something twice isn't enough to justify abstracting it out just for the sake of being DRY. In only the most simple programs will something that you use a third time be exactly the same as the first two times you did it. Waiting until you've repeated yourself three times helps you know what it is that you're actually repeating.
I can live with that. I usually stop and abstract when I find myself repeating something the 2nd time because I don't want it to spiral out of control. I've been criticized in code reviews for abstracting too much into methods, some of them only having one or two lines. I abstract things early which may be repeated... that arguably can be another form of YAGNI lol.
But I do like the "do one thing and do it well" philosophy. 3 times is reasonable.
I will not abstract prematurelyI will not abstract prematurelyI will not abstract <when><who> will not abstract <when><who> will <shouldAbstract ? '' : 'not'> abstract <when>oh no
01:26 AM - 09 Aug 2019
Guilty. But lots of abstractions means faster running unit tests, right?
Not sure if you're sarcastic here, but if you're not our units under test originate in very different testing philosophies.
Context is crucial too...you can have the same code show up in different places with completely different contexts which looks repetitive, but it makes no sense to de-duplicate something that crosses system boundaries.
Absolutely right. Sometimes you can have the exact code verbatim and working off two different input/outputs. One of those implementations may change without the other so by de-duping and putting into a method you can be creating a regression.
This is why software engineering is so fun! (not saying it sarcastically)
duplication is better than the wrong abstraction :D
most of the time, yes
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.