Sometimes it is more difficult to modify an abstracted component to fit a specific use case.
This is a problem with your abstraction and not DRY. Another commenter mentions a similar problem with having lots of conditionals in their abstractions. That's another symptom of the sale problem, the wrong abstraction.
Also, I'd be concerned about your rubric, "haven't I written this before?" That really only applies when you are the only developer in the code. Hopefully, code review would catch this. I think you have to be a little more conscientious about this in shared code base since no one developer is likely to know all the versions of the same code there are floating around.
Also, I'd be concerned about your rubric, "haven't I written this before?" That really only applies when you are the only developer in the code. Hopefully, code review would catch this. I think you have to be a little more conscientious about this in shared code base since no one developer is likely to know all the versions of the same code there are floating around.
This is a super valid point! It's a concern with DRY as well, since if multiple developers don't know the full codebase, they are likely to abstract something multiple times. To me this all comes down to making sure you have well commented code and making team communication easy. Code Reviews also help you catch these problems before they hit the main branch.
One of the arguments for doing it this way is that having three examples to abstract from is more likely to give a generally useful abstraction than the first two. It's not a hard and fast rule though - sometimes when you need the second instance, it's obvious there will be more later, sometimes you find several instances later that the abstraction could be improved and go back to the first few instances to refactor them.
And trying to force a specific use case that doesn't really fit to the wrong abstraction because otherwise you might repeat some bits of it is a symptom of the same problem. Sometimes it means your abstraction would benefit from having parts refactored out separately, sometimes it's better just to have a comment saying "this looks like , but that's not a good fit because ". But if you find the same comment being written three times, rethink the refactor....
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.
This is a problem with your abstraction and not DRY. Another commenter mentions a similar problem with having lots of conditionals in their abstractions. That's another symptom of the sale problem, the wrong abstraction.
Also, I'd be concerned about your rubric, "haven't I written this before?" That really only applies when you are the only developer in the code. Hopefully, code review would catch this. I think you have to be a little more conscientious about this in shared code base since no one developer is likely to know all the versions of the same code there are floating around.
But, your point is still valid. Nice summary.
This is a super valid point! It's a concern with DRY as well, since if multiple developers don't know the full codebase, they are likely to abstract something multiple times. To me this all comes down to making sure you have well commented code and making team communication easy. Code Reviews also help you catch these problems before they hit the main branch.
One of the arguments for doing it this way is that having three examples to abstract from is more likely to give a generally useful abstraction than the first two. It's not a hard and fast rule though - sometimes when you need the second instance, it's obvious there will be more later, sometimes you find several instances later that the abstraction could be improved and go back to the first few instances to refactor them.
And trying to force a specific use case that doesn't really fit to the wrong abstraction because otherwise you might repeat some bits of it is a symptom of the same problem. Sometimes it means your abstraction would benefit from having parts refactored out separately, sometimes it's better just to have a comment saying "this looks like , but that's not a good fit because ". But if you find the same comment being written three times, rethink the refactor....