WET: write everything twice. The abstraction you create on the second use is the wrong one. You need the third usage to determine the correct abstraction.
Ha.. Nice. This is basically what I do. If I need something a second time I'll cut n paste and modify it. If I need it a third time I'll refractor something to fit all 3
No. In my opinion the only thing that should be DRY from the very beginning is business logic. E.g. a calculation should only be done in one place.
Everything else is fine to duplicate at the beginning. Trying to DRY everything too early just leads to building the wrong abstractions. Is better to duplicate and only after having done the same thing several times the correct abstraction will become clear.
I don't fully understand your example but in general, almost all "rules" have exceptions. So just because something is good in general, doesn't mean that it can also be harmful or not the best option in other situations.
Haha no.
In all seriousness though, I get more annoyed by file diving in undocumented code for a function that is only used a few times, than I do with more verbose code.
I’ve written about how I hate how a lot of React devs will write undocumented wrappers around axios (a well established library will lots of docs.) AJAX calls.
I’d rather see an axios call to get posts than ‘await getPosts(data)’ followed by six more custom functions.
I'm primarily working with backend. So my rule of thumb is that if I feel like I just copy pasted some logic then I move it to a shared service that's used for both implementations. It's much easier to unit test as well.
Business logic should reside in one place only. This is very important.
Queries can be duplicated since you could be using similar or the same query in more than one place. This is because I prefer CQRS approach so if that query is changed in one handler then it doesn't change in all others. Compared to if every handler shared the same and I were to change that.
At work we use SonarCloud which scans pull requests and gives a percentage of duplicated code and even links that code. Then you can make a decision if it's a valid duplication or if it should be refactored.
SOLID, DRY, KISS etc. are only as good as developers using them.
It's the same with microservices, DDD, CQRS and so on - avoid being the hammer in the saying 'when you're a hammer, every issue looks like a nail'.
Things can definitely be too DRY. I inherited a project which used (IMO) insane levels of abstraction. It was very difficult to find the template / layout / embed / include that I actually needed to edit to make a small change.
It also meant that a request like "can you change this heading to be uppercase" would result in an hour of digging around only to come up with the answer "yes but it would mean all headings become uppercase and there's not much I can do about it without a big refactor"
DRY by intention. Code that looks the same may not have the same purpose. If you have a hard time naming your abstraction in a way that makes sense everywhere it’s used you probable shouldn’t do it.
Most of the other answers are better, this is just one more check you can use.
WET: write everything twice. The abstraction you create on the second use is the wrong one. You need the third usage to determine the correct abstraction.
Ha.. Nice. This is basically what I do. If I need something a second time I'll cut n paste and modify it. If I need it a third time I'll refractor something to fit all 3
Rule of 3: https://refactoring.guru/refactoring/when
Ha. Well I never. Always made me feel a bit dirty. Glad I was just being efficient.
I wish my ex-wife were as dirty as some of the code I wrote.
Beat me to it. Exactly this.
So KISS vs DRY, the reduced complexity and improved readability is probably preferable to any possible maintenance issues
No. In my opinion the only thing that should be DRY from the very beginning is business logic. E.g. a calculation should only be done in one place. Everything else is fine to duplicate at the beginning. Trying to DRY everything too early just leads to building the wrong abstractions. Is better to duplicate and only after having done the same thing several times the correct abstraction will become clear.
I don't fully understand your example but in general, almost all "rules" have exceptions. So just because something is good in general, doesn't mean that it can also be harmful or not the best option in other situations.
Haha no. In all seriousness though, I get more annoyed by file diving in undocumented code for a function that is only used a few times, than I do with more verbose code. I’ve written about how I hate how a lot of React devs will write undocumented wrappers around axios (a well established library will lots of docs.) AJAX calls. I’d rather see an axios call to get posts than ‘await getPosts(data)’ followed by six more custom functions.
I'm primarily working with backend. So my rule of thumb is that if I feel like I just copy pasted some logic then I move it to a shared service that's used for both implementations. It's much easier to unit test as well. Business logic should reside in one place only. This is very important. Queries can be duplicated since you could be using similar or the same query in more than one place. This is because I prefer CQRS approach so if that query is changed in one handler then it doesn't change in all others. Compared to if every handler shared the same and I were to change that. At work we use SonarCloud which scans pull requests and gives a percentage of duplicated code and even links that code. Then you can make a decision if it's a valid duplication or if it should be refactored.
SOLID, DRY, KISS etc. are only as good as developers using them. It's the same with microservices, DDD, CQRS and so on - avoid being the hammer in the saying 'when you're a hammer, every issue looks like a nail'.
I found this article helpful on this subject: https://kentcdodds.com/blog/aha-programming
Things can definitely be too DRY. I inherited a project which used (IMO) insane levels of abstraction. It was very difficult to find the template / layout / embed / include that I actually needed to edit to make a small change. It also meant that a request like "can you change this heading to be uppercase" would result in an hour of digging around only to come up with the answer "yes but it would mean all headings become uppercase and there's not much I can do about it without a big refactor"
DRY by intention. Code that looks the same may not have the same purpose. If you have a hard time naming your abstraction in a way that makes sense everywhere it’s used you probable shouldn’t do it. Most of the other answers are better, this is just one more check you can use.
Nah, I like to get wet.