The principle is called “don't repeat yourself”.

Caveats:

  • 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.