Which code to copy-paste and which to centralize?

Question

In a fairly complex system with a dozen or more git repositories, most of them are done in a cookie-cutter fashion.

What is or would be your best approach to deal with duplication?

In my opinion the project creation could become a template so that you can easily scaffold another project. (so not centralized but copypasted) I would avoid centralize this code because it makes the application very stiff regarding i/o capabilities, security constrains and interfacing with your metal or cluster.

Then there is the business logic, which I would centralize in the parts that belong to the same model in the same bounded context. Copy pasting here means ensuring bugs crop up from diverging codebases.

Finally there is utility codes which appear over and over but are not part of the business logic, for example some code related to logging or monitoring. I would just copy and paste that. Centralizing this kind of code does not bring any advantage.

Answer 1

If I understand you correctly then you should always ask:

When I want to do the same things inside of function A and inside of function B and somewhen the requirement for this implementation changes in function A: What is the probability that this change should also be applied in function B? If high probability: Centralize/Outsource this and avoid duplicated code. If low probability (maybe because the functions are only "randomly" doing some similar things): Do not outsource this, copy&paste is ok because semantically there are 2 two different things so the implementations should be independent.

Answer 2

Don’t Repeat Yourself (DRY) can be over applied. If you see x = 10 and y = 10 together it doesn’t mean you need to replace y with x. Here x and y mean different things even if they happen to hold the same value. Eliminating y destroys information and harms flexibility.

It’s the same with lines of code. Just because two functions happen to have the same lines of code within doesn’t mean one must be eliminated. Those functions do the same thing but depending on their names and what they are obligated to support when called they can still be very different functions. Ones that may soon change independently.

You must protect that need to change independently when it exists. It can be just as real as the need to change together when you’re copying around a bug.

But none of that is an excuse to blindly copy and paste duplicate code everywhere. Never just focus on getting done what needs to be done. Always keep an eye on how well you’re showing why you’re doing what you’re doing.

Unexplained duplicate code causes a serious problem because it’s been stripped of it’s meaning. Without meaning people fall back on dogma to make decisions and DRY gets over applied. If you dupe, make why you dupe clear.

Answer 3

Say you are in the UK. You have a function that adds 20% to a price. But in reality, its responsibility is to add the correct VAT, whatever that is, not 20%.

That function should be in a central place, so if you need to change it (which you would have a few times in the last ten years), it’s one change and it’s changed everywhere.

Now you have another function that converts feet and inches into meters. That function is never going to change. You can duplicate it as much as you like.

And what was mentioned elsewhere: “Add 20%” might really mean “Apply the correct VAT” or “Add some stuff for free on large orders”. So these MUST be two different functions with possibly identical code.