Clean Code: DRY code controversies and the Monster of the Wrong Abstraction

DRY, "Don't repeat yourself", is a principle in software development that has been followed by a large part of the programming community and basically consists of making abstractions to avoid repetitions, don't worry if it's a bit confusing, during this post we'll break down these definitions and concepts.

Why is it so used?

As you can imagine, the technique is used to prevent us from copying and pasting parts of our code that are identical, and in fact, it is an extremely strong principle, which can improve the organization and unify functions, making a bug easier to find and fix.

But it's not all rosy, well, when the projects are bigger complexity increases, and with that, we abuse the principle, using it everywhere in our code, and it's in abstractions that the situation starts to get complicated.

This post takes strong inspiration from Kent C. Dodds' conversation on post AHA Programming and by Dan Abramov at The WET Codebase.

What are abstractions?

Abstractions are basically functions or components (if using React or something similar), with the intention of automating a certain process. An example is libraries such as Ant Design, MaterialUI and others, which provide components that can receive certain props, and these props are used to "make the component your own way". Let's look at a simple example.

An abstraction is something that we can reuse and, if necessary, add more complexity, such as the following function, which behaves uniquely at certain ages.

The monster of wrong abstraction.

If you've ever used this principle in a more complex project, you've certainly been confused when you stop to think, how you should transform similar code into a function that supports all cases, and in case this project got a little longer and complicated, so probably your abstraction got complexier too.

Prefer duplication over the wrong abstraction.

The important thing is to know when to break an abstraction if it is getting more and more complex and harder to manage and implement features to support several cases, the solution is to break it to avoid a headache, and so, we enter another programming principle.

YAGNI

"You aren't going to need it" is another principle of software development, and it consists of not doing complex code because you will not need it.

Technologies change, features must be added constantly, you don't have to struggle to put a thousand packages or frameworks, just do what you need. As much as this principle makes everyone think that you shouldn't make an effort, the real thing is that you don't need to complicate things too much!

Conclusion

As much as these principles may seem, they are no rules, you are free to test what is best for you and experiment what works. Don't take the content of this post as a good way to be followed, because nobody owns the reason and I'm too far to say what is right to be followed. I hope this post cleared your mind, let me know what you liked and if it was helpful!