This is interesting. I always apply DRY to my business logic: "make sure every time you validate the sales order, it's done through the same method." vs with my programming concepts like: "make sure that every time you validate that a field is present, it's done in the same method."
I've found that as my software ages, the parts that break are the ones which are coupled together for the reason of allowing a developer to write less lines over the ones which must be done the same from a business perspective. I always ask myself, "Would I expect X user flow to break if Y breaks." Then if I do, I consider coupling it together.
You seem to have a different experience. What techniques do you use to manage wide dependency trees this could create? Do you find that this creates wide dependency trees?
(I'm hoping this doesn't come across as confrontive. I'm honestly trying to ask a question while giving a bit of background... it's hard without body language lol)
Haha I totally visualize you as a person waving your hands now.
I think my main thing is thinking out the full application on paper to help with this.
There we write out what could change for a reusable element.
But as you might know, requirements change, and this can cause hectic changes, and break for one of the things.
Just the other day created a super re-usable input component, could handle about anything, except for large file upload.
Trying to wire that into it, was just breaking about everything, so decided to deduct it, it's not neat and nice, and what you want, but sometimes it's also a good mix of time vs effort vs result.
I hope I got your question right here, also up for discussion on points like this ✌️
Ah, that also might be part of it :). My current job has a simple front end and endlessly complex back end, so I'm mostly thinking of API calls. I could totally see designing a reusable component
This is interesting. I always apply DRY to my business logic: "make sure every time you validate the sales order, it's done through the same method." vs with my programming concepts like: "make sure that every time you validate that a field is present, it's done in the same method."
I've found that as my software ages, the parts that break are the ones which are coupled together for the reason of allowing a developer to write less lines over the ones which must be done the same from a business perspective. I always ask myself, "Would I expect X user flow to break if Y breaks." Then if I do, I consider coupling it together.
You seem to have a different experience. What techniques do you use to manage wide dependency trees this could create? Do you find that this creates wide dependency trees?
(I'm hoping this doesn't come across as confrontive. I'm honestly trying to ask a question while giving a bit of background... it's hard without body language lol)
Haha I totally visualize you as a person waving your hands now.
I think my main thing is thinking out the full application on paper to help with this.
There we write out what could change for a reusable element.
But as you might know, requirements change, and this can cause hectic changes, and break for one of the things.
Just the other day created a super re-usable input component, could handle about anything, except for large file upload.
Trying to wire that into it, was just breaking about everything, so decided to deduct it, it's not neat and nice, and what you want, but sometimes it's also a good mix of time vs effort vs result.
I hope I got your question right here, also up for discussion on points like this ✌️
Ah, that also might be part of it :). My current job has a simple front end and endlessly complex back end, so I'm mostly thinking of API calls. I could totally see designing a reusable component
Yes! This makes me realize that DRY is SPOT as seen by a developer.
Is SPOT single point of termination? I hadn't heard that acronym before :)
Single Point of Truth, really.