Erm. Duplication of code is ok. Removing absolutely every duplicate function is just premature optimization imho.
If you have two different customers with slightly different workflow then go ahead and create two mostly the same functions. When you will have 4 different customers with slightly different workflow, then its a time for refactoring, maybe extract basic same functionality into separate function/object, maybe introduce dynamic workflow using finite automata, maybe extract these functionality to separate modules… but never do it prematurily.
Imho, sometimes ,removing of duplication very much increases complexity and code became hard to understand and hard to modify.
My understanding of that article was that it was not necessarily about duplicated code, but duplicated data. If you have two places storing the same data, and different parts of your app go to each of it, you need to somehow keep them in sync, and that’s often a pain.
I’m trying to be very rigorous about avoiding that, duplicated code I’m a bit less rigorous about.
Microservices and document db’s go brrrrrrr. Data duplication is completely fine as long as there is only one source of truth that can be updated, all copies must be read only. Then the copies should either regularly poll the source or the source should publish update events that the copies can consume to stay in sync. It’s simple stuff but keeps your system way more available and fast than having multiple services talk to a shared db or worse, multiple services constantly fetching data through a proxy.
While you may be correct, if you’re on a dogmatic team, work with dogmatic people, or are a part of a dogmatic company, you probably need to avoid duplication. This is because duplicate code is an easy thing for a reviewer to nitpick and reviewing code can sometimes be more about showing off and less about ensuring code quality.
Erm. Duplication of code is ok. Removing absolutely every duplicate function is just premature optimization imho.
If you have two different customers with slightly different workflow then go ahead and create two mostly the same functions. When you will have 4 different customers with slightly different workflow, then its a time for refactoring, maybe extract basic same functionality into separate function/object, maybe introduce dynamic workflow using finite automata, maybe extract these functionality to separate modules… but never do it prematurily.
Imho, sometimes ,removing of duplication very much increases complexity and code became hard to understand and hard to modify.
https://en.m.wikipedia.org/wiki/Rule_of_three_(computer_programming)
Copy for twice, abstract for thrice. I’ve followed this since I learned it and it’s served me well.
Edit: Wikipedia links are fucky
My understanding of that article was that it was not necessarily about duplicated code, but duplicated data. If you have two places storing the same data, and different parts of your app go to each of it, you need to somehow keep them in sync, and that’s often a pain.
I’m trying to be very rigorous about avoiding that, duplicated code I’m a bit less rigorous about.
Microservices and document db’s go brrrrrrr. Data duplication is completely fine as long as there is only one source of truth that can be updated, all copies must be read only. Then the copies should either regularly poll the source or the source should publish update events that the copies can consume to stay in sync. It’s simple stuff but keeps your system way more available and fast than having multiple services talk to a shared db or worse, multiple services constantly fetching data through a proxy.
While you may be correct, if you’re on a dogmatic team, work with dogmatic people, or are a part of a dogmatic company, you probably need to avoid duplication. This is because duplicate code is an easy thing for a reviewer to nitpick and reviewing code can sometimes be more about showing off and less about ensuring code quality.