DRY: Don't Repeat Yourself
Tags: beginners, architecture, software, codequality
Published: 2023-03-10 18:02:50

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jblwifcnecpy1bwkrdvr.jpg)


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**(**D**on't **R**epeat **Y**ourself) 

## What is DRY ?


![do not repeat yourself javascript class](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/57l2m9h8gbccs4euitrh.png)

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 : 

```javascript
// 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}`

.....
}
```

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. 

```javascript
//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);
.....
}
```

## 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](https://twitter.com/Guialajr)