3 ms·
I've seen code like this, what eventually happens is that all your 'copies' drift to be slightly different. Fixes get applied to some but not all of them, peopl
by DSMan195276 2y ago
I've seen code like this, what eventually happens is that all your 'copies' drift to be slightly different. Fixes get applied to some but not all of them, people copy from old code vs. new code, etc. And whenever you need to apply a fix you spend hours trying to figure out where each copy is, what it is supposed to be doing (since they're all different), and how the fix can be applied to it. You inevitably don't find them all and repeat the cycle.
- YZF 2y agoThis is also true. Some versions can be buggy and then a fix might not get everywhere. My favorite example is C code bases with a multitude of linked list implementations. Like many things in software knowing when to do something and when not to do something can be hard. Premature DRY as the article mentions can lead to difficulty when eventually the use case diverges. Re-implementing everything every time everywhere is also silly. As mentioned in other places, I like the rule of 3, if you have 3 examples the point strongly a certain direction that's probably a good one to follow.
- tcfhgj 2y agoWhich tool do you use to manage the copies of code segments, including possible modifications? I imagine it's difficult to keep all of them in your head
- YZF 2y agoIt's just like any other code. But I think you might be onto something in terms of tooling help to manage that. I've had some ideas around this. I'll throw this out and if it turns into a billion dollar business please look me up for my share, treating code not as text files but as something deeper with metadata associated with it.
- DSMan195276 2y agoI think the key is more to ask yourself what it is you're abstracting away and whether the two things are actually doing the same thing. Just because the code is "shaped" in the same way (as in the article) doesn't mean it's actually conveying the same idea. If they're not really the same then the abstraction won't make sense and will just make things messier down the road. It's the same thing as naming constants, but with code. If I have 3 `10` magic numbers in my code, I don't just immediately abstract them into a `const ten = 10` because they look the same, I abstract them into constants based on their actual purpose.