Our guideline is that it is good to apply DRY when two different pieces of code are doing the same thing for the same reason. Because it costs extra labor to maintain multiple copies of the same non-trivial code. It also happens to be quite boring to repeat the same changes multiple times. The situation changes slightly when we are talking about sharing the same code between two different projects. This kind of sharing has a much higher overhead cost (creating, maintaining, versioning a package shared between projects). So the tradeoff has to be weighed and it is not clear cut.
DRY usually does not make sense in the case where I have two different sets of code that happen to have similar mechanics. This is a common trap that devs fall into -- "I want to solve this problem once for all similar cases." To do that, I have to invent an abstraction to unify the different cases. And the user of my abstraction has to learn how to properly call my DRY code to engage the correct path through. This is a bad user experience that inspires anxiety in users of my code rather than confidence. I have done this many times, and often the user that it gave anxiety was me in the future.
Practices like DRY are only good when they are used in an appropriate situation. When we try to make good practices into a law that must always be followed, we destroy the value of it. Then it turns into ammunition that we needlessly shoot at each other.
It seems that what I felt was completely verbalized.
And you seem to be able to objectively evaluate how effective the method is. without stereotype.
Yeah stereotype, this is what I felt uncomfortable.
"Method X is great, but you don't follow X at the point, so you need more practice." I hate that.
And you mentioned how does fat of god class start? At the 3rd paragraph.
literally thoughtful comment, I'll quote the comment when the discussion of programming practices begins.
I really appreciate you, and also I want to be an engineer with such a hardcore thought. 🙇♂️
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the question!
Our guideline is that it is good to apply DRY when two different pieces of code are doing the same thing for the same reason. Because it costs extra labor to maintain multiple copies of the same non-trivial code. It also happens to be quite boring to repeat the same changes multiple times. The situation changes slightly when we are talking about sharing the same code between two different projects. This kind of sharing has a much higher overhead cost (creating, maintaining, versioning a package shared between projects). So the tradeoff has to be weighed and it is not clear cut.
DRY usually does not make sense in the case where I have two different sets of code that happen to have similar mechanics. This is a common trap that devs fall into -- "I want to solve this problem once for all similar cases." To do that, I have to invent an abstraction to unify the different cases. And the user of my abstraction has to learn how to properly call my DRY code to engage the correct path through. This is a bad user experience that inspires anxiety in users of my code rather than confidence. I have done this many times, and often the user that it gave anxiety was me in the future.
Practices like DRY are only good when they are used in an appropriate situation. When we try to make good practices into a law that must always be followed, we destroy the value of it. Then it turns into ammunition that we needlessly shoot at each other.
Thank you for your reply!
My apologize is I can't get your thought correctly with after work fatigue at the 23:12pm(JST) 😭
Actually I'm curious about it and tomorrow's me absolutely reading this and make a response!😪
I'm so sorry. I couldn't do what I said🙇♂️
It seems that what I felt was completely verbalized.
And you seem to be able to objectively evaluate how effective the method is. without stereotype.
Yeah stereotype, this is what I felt uncomfortable.
"Method X is great, but you don't follow X at the point, so you need more practice." I hate that.
And you mentioned how does fat of god class start? At the 3rd paragraph.
literally thoughtful comment, I'll quote the comment when the discussion of programming practices begins.
I really appreciate you, and also I want to be an engineer with such a hardcore thought. 🙇♂️