The way I tie these together in phrasing it to teams is to ask yourself “Is this _necessarily_ the same or _coincidentally_ the same?”.
Code which is necessarily the same might be something like “how to calculate an invoice total”. If you need to calculate totals in multiple places, you can’t calculate different totals for the same invoice. Have a single source of truth for this.
Code which is coincidentally the same might be something like “well, to get an invoice total we add up all these prices multiplied by quantity… and this spreadsheet we’re importing has the product cost and a multiplier to reach a desired profit, so that’s the same dollar amount multiplied by a number again!”. Creating a single implementation for this will only cause pain.
Even if these things are the same _right now_, there’s nothing saying they must remain the same. And as they diverge, you are going to be either creating brittle franken-code that causes bugs in seemingly-unrelated parts of the application when you make (slow, tedious) changes, or you’re going to keep only the repeated logic as it evolves and you will make the code more and more generic until it provides no useful abstraction whatsoever.
Don’t repeat things that must be the same. Do repeat things that just happen to be the same _right now_.
> The way I tie these together in phrasing it to teams is to ask yourself “Is this _necessarily_ the same or _coincidentally_ the same?”.
I'm a hobbyist. One of my apps recently had the exact same five lines of code in two functions.
After some thinking I decided to leave it like that. Moving it into a third function seemed just additional work without no benefit.
My question was: if I had to change A, would I have to change B? The answer was: Perhaps, but not in all cases. And if I had to, the change would have me look at both functions anyway, so it is not that I could just forget to change B. And it would be unlikely it changes at all in the next 2 years.
Code which is necessarily the same might be something like “how to calculate an invoice total”. If you need to calculate totals in multiple places, you can’t calculate different totals for the same invoice. Have a single source of truth for this.
Code which is coincidentally the same might be something like “well, to get an invoice total we add up all these prices multiplied by quantity… and this spreadsheet we’re importing has the product cost and a multiplier to reach a desired profit, so that’s the same dollar amount multiplied by a number again!”. Creating a single implementation for this will only cause pain.
Even if these things are the same _right now_, there’s nothing saying they must remain the same. And as they diverge, you are going to be either creating brittle franken-code that causes bugs in seemingly-unrelated parts of the application when you make (slow, tedious) changes, or you’re going to keep only the repeated logic as it evolves and you will make the code more and more generic until it provides no useful abstraction whatsoever.
Don’t repeat things that must be the same. Do repeat things that just happen to be the same _right now_.