The principle is called “don't repeat yourself”.
- repeating code
- but pay attention to the semantics, not always repeating code is the same code, sometimes code looks the same, but in reality it's not duplicated
- pay attention to SRP – repeat code if the stakeholder who asks you to change that code is different – respecting SRP
- sometimes repeating code is more than just code, it's also constants with the same values; beware of semantics; listening to these hints can help weed out irregularities in the grander architecture
The biggest challenge with this principle is finding a good balance between SRP and DRY.
Not always you want to DRY at the price of violating SRP.
To understand the reason, let's take as an example two components A and B, each for a different stakeholder.
Let's say both A and B have some shared functionality. You have two options: you duplicate the code in both components, respecting SRP.
Or you respect DRY by extracting the common code into a shared component S, but who is the stakeholder of this component?
The problem: if stakeholder A asks you to make changes in his component, and the change requires a change to S also, you risk introducing bugs in the component B of the other stakeholder.
For this reason, a balance must be struck between DRY and SRP. Sometimes, simply duplicating the code momentarily might lead to more stability in the long term.