First, I’m Sorry for the Clickbait-Y Title, But We Need to Talk About It don’t repeat yourself ,dry) Theory.
A few years ago we were asked to help with further development of existing platforms in the blockchain industry. It was a product aimed at merchants and helped them automate tax filing. And it was the biggest copy and paste-based project I’ve seen in my life.
It was written in PHP. If you know PHP you know that each
.php The file acts as the entry point to your code – and from there you usually import (include) utilities, libraries that are common to your project. That is if you don’t use the framework. It didn’t.
This project was created from the start by its founder who learned programming while building and maintaining the product.
They didn’t already have much programming knowledge and didn’t know all these good practices and fancy rules that we have. so each
.php The file was a copy of the previous one containing the necessary modifications for the given route/scene. Tons of code over and over again.
And here’s what’s really important: At this point the product has already made millions of dollars.
Let it sink No amount of copied code, duplication, and what we call “poor quality code” prevented the product from being successful.
What’s more, we were able to identify duplicated code very quickly and introduce the correct abstractions because we already knew the use cases that were different from the duplicated code.
I know developers who didn’t live to repeat themselves. I think at some point they’re better off “in general not to do a lot of repetition” than “if you repeat any code you will burn to hell”. This is one of these stories.
We were working in a company that had several related products. And something that one of the developers blew my mind. They were working on a new application and decided they could just use a two-line function from a previous project (3 lines if you count the definition of the function).
Here the choice was simple – copy these 3 lines of code to the new project. But as many developers think – this one included – “repetition is the root of all software evil”. so they spend two days setting up a common library (including deployment process etc) so they don’t duplicate 3 lines of code,
Now ask yourself how does this benefit the project and how does it bring us closer to meeting our objectives.
source of all evil
Just by googling “don’t repeat yourself” I learned that:
- Repetition is the root of all software evil
- repetition sucks
- If you do it you don’t understand how to apply abstraction
- It degrades the quality of the code
- it should all be over
It sounds like a bad idea, doesn’t it? but this time it Looks like we slander it, Looks like you’re a bad developer if you do! E.g. there is no scenario where you should be doing this. But you would be using StackOverflow, right?
Have you ever asked yourself a simple question – is it true? He bad that i copy and paste a bit of code? Does it have any advantage?
Only one Sith deals in absolutism
Here’s the thing – in software development every rule makes sense at most 80% of the time. Each was coined in a specific context—for which it made sense. But that context got lost in translation and some people Follow the rule religiously instead of treating it as a rule of thumb,
This is our fault. we make those principles sound so absolute, Don’t repeat yourself means don’t repeat yourself. It is then passed from person to person, copied over and over again on blogs, books, until it becomes true and all the context and all the nuances are lost.
So here’s an alternative that I think some of you should try:
Try not to repeat yourself too much. But sometimes you can. Because sometimes it makes sense.
It’s not that catchy phrase though.
repeat yourself please
This rant is already getting too long for my taste, so let’s get to the point. There are many cases where don’t repeat yourself Not an anti-pattern but it’s actually a tool,
I like to repeat myself. Especially when I am writing tests. I copy tests all over the place and change what is needed for the given test. This results in a lot of duplication. When I’m done I’ll just go through these tests and see what’s the best way to reduce (not completely eliminate) repetition and what can be taken out in different essences.
I could spend a lot of time figuring out how I wanted to set up the tests, what helpers I needed, then redoing everything because it turns out that 2 of the 25 tests required a slightly different setup. Is. But why would I do this if I can just see where the code takes me? Instead of guessing it all, why not see what’s really needed?
It’s not just for tests, but tests are where it’s most obvious and I would encourage you to start there.
overuse of dry (don’t repeat yourself) That in itself is an anti-pattern. Removing overzealous duplication leads to bad abstraction because the developer abstracting the imaginary instead of exposing the real,
Repeating yourself is basically giving yourself the time and space to come up with the right essence. Instead of guessing and engaging in foresight. We don’t know what the future code will be. We don’t understand all of the first use cases or ways of using our code. If we introduce abstraction too soon then in best case we rewrite everything.
Repeating yourself is a great tool for uncovering abstractions.
what other people say
As you might have guessed I’m not the first to notice this. There are two great articles on this topic:
You should definitely read them as they well enhance this article and will give you a greater understanding about when to use repetitions. Here are some excerpts:
“repetition is far cheaper than false abstraction”
“Prioritize repetition over the wrong abstraction”
– Sandy Metz, “The Wrong Abstraction”
“Adapt for the first change”
,big takeaway The thing about AHA programming is that you don’t have to be dogmatic when you start writing abstractions, rather write abstractions when it feels right and don’t be afraid to duplicate code until you get there.
– Kent C Dodds, “Aha Programming”
I want to clarify that I am not inviting you to make a mess. I’m pointing out that some level of temporal repetition is healthy. The first story is going to show you what you might think – the success of a product doesn’t depend on it, but it depends on the growth of the business.
So copy the code and modify it if needed to place yourself so that you expose the real essence rather than the imaginary. Of course – that’s not the only way to expose a better abstraction. Talking to stakeholders and understanding the business better is another approach that we will discuss in the future. But this is not a situation where you need to choose one over the other, but complementary approaches.
There are a lot of rules – or “good practices” – in software development. Usually they work when you understand the context and apply them intelligently. Sadly, there is a lot of dogma in the software industry, driven by hype and emotion and rarely by pragmatism. So remember that these “good exercises” are not “all or nothing”, but rather “try doing it more than anything else and you’ll be good”.