DEV Community

Cover image for DRY: Don't Repeat Yourself
Jean Roger Nigoumi Guiala
Jean Roger Nigoumi Guiala

Posted on • Edited on

DRY: Don't Repeat Yourself

A software engineering principle.

The problem

As a software developer , it's all about finding solutions to problems. Being able to build something that will solve a specific task.
When you are just starting your journey, it will often be around just finding a way to solve a problem, making something work by using a specific language/technology.

But at some point in your journey, it's not only about making it work , it's making sure you can be able to build on top of it; iterate and also allow people to contribute without impeding the work. There is that meme of coming back to the code you wrote a years ago and not understanding anything, I think it speaks to most of us in the software industry.

coming back to the code you wrote

So it's not only about coding , but building something that can last using tools and principles; just like building a car , a house. And that is called Software engineering

On Wikipedia a software engineer is define as

a person who applies the principles of software engineering to design, develop, maintain, test, and evaluate computer software. The term programmer is sometimes used as a synonym, but may also lack connotations of engineering education or skills.

One of those principles is called DRY(Don't Repeat Yourself)

What is DRY ?

do not repeat yourself javascript class

The Dry Principle that was popularized by the book The Pragmatic Programmer by Andy Hunt and Dave Thomas (That I encourage you to read of course), in that book they state that :

“every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

Basically , write only once. A rule of thumb is , if you find yourself writing something twice (a knowledge), it should be refactored(a single function, module, Abstract etc) and reused everywhere.

take a look at this example :

// not DRY

//file 1 
export function infoOfRectange(rectange) {
 const area = rectangle.length * rectangle.width; 

return {
 area, 
name: rectangle.name
}


//file 2 use the area to compare two rectangle
export function compare_area(rectangle1, rectangle2){
const area_rectangle1 = rectangle1.length * rectangle1.width;

const area_rectangle2 = rectangle2.length * rectangle2.width;

if(area_rectangle2 > area_rectangle2) return `${rectangle2.name} has a greater area than ${rectangle1.name}`

.....
}
Enter fullscreen mode Exit fullscreen mode

Here we have two different function that uses the area of the rectangle, according to the definition, the area here is a knowledge so that knowledge needs to have a single representation.
So in our context , applying the DRY principle means having a single source of truth for that.

//dry
export function rectangle_area(length, width){
   return length * width;
}

//calling that function in `compare_area`

export function compare_area(rectangle1, rectangle2){
const area_rectangle1 = rectangle_area(rectangle1.length, rectangle1.width);

const area_rectangle2 = rectangle_area(rectangle2.length, rectangle2.width);
.....
}
Enter fullscreen mode Exit fullscreen mode

Do not over engineer

Now that we have learned about Dry , One common mistake is over engineering , meaning refactoring when we don't need to. Because in software development every second cost something and also it's not necessary to bring complexity in our system when it's not needed meaning when we don't have duplicate, when a knowledge is only necessary in one place, it's already DRY and thus we don't need to separate everything.
I will refractor this because it could be useful later This statement should be a red flag and as we said above can cause many issue :

  • introducing more complexity

  • introducting more coupling between our features

  • Cost (is it necessary ?, can this time be spent on something else)

This introduce another principle known as KISS (Keep it Simple Stupid). it translates simply to Do not over engineer

If you have some other example or tips , feel free to share them in the comment section, as well as questions :).

You can follow me on twitter : @Guialajr

Top comments (0)