DEV Community

Cover image for Software design principles: DRY

Software design principles: DRY

Chris Bongers on November 16, 2020

Today we'll be exploring a design principle called DRY it stands for Don't Repeat Yourself. Of course, a pretty obvious one, meaning you shouldn't ...
Collapse
 
winstonpuckett profile image
Winston Puckett • Edited

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)

Collapse
 
dailydevtips1 profile image
Chris Bongers

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 ✌️

Collapse
 
winstonpuckett profile image
Winston Puckett

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

Collapse
 
xtofl profile image
xtofl

Yes! This makes me realize that DRY is SPOT as seen by a developer.

Collapse
 
winstonpuckett profile image
Winston Puckett

Is SPOT single point of termination? I hadn't heard that acronym before :)

Thread Thread
 
xtofl profile image
xtofl

Single Point of Truth, really.

Collapse
 
jqn profile image
Joaquin Guardado

Cool topic Chris, you should check out this video by Kent C Dodds where he goes deeper into when and why to use DRY and when other patterns are more applicable.
youtube.com/watch?v=wuVy7rwkCfc&li...

Collapse
 
dailydevtips1 profile image
Chris Bongers

Oh nice one, added to my watch list, thanks Joaquin! ✌️

Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️ • Edited

I highly recommend reading the chapter Beware the Share from the book 97 Things Every Programmer Should Know. Probably also the section Don't Repeat Yourself.

Collapse
 
dailydevtips1 profile image
Chris Bongers

Oh that first chapter you mention is such a good story part actually!
Nice addition.

Collapse
 
dailydevtips1 profile image
Chris Bongers

Whahaha, love this!

Yeah IoC is harder to fully wrap your head around, if explaining it as DRY it's easier for beginners, and even experienced devs.

I tend to look at my code like an 8-year-old quite a lot, would I understand it, would I be able to use it etc.