I've tried to write a comment here three times, and then deleted it. This one is the fourth. :) I'm not sure what's bothering me here. The idea of refactoring at the bottom is good. Smaller abstractions are perfect. But the idea of just leaving duplicated code makes me feel uneasy. And even that is not completely true. The idea of leaving duplicated code and feeling that it is ok, that's what I think is not good.
What I think would be slightly better, is to refactor anyway, even if it is duplicated "only" in two places, and there's a good chance that this code will be used more. I see two rules here: 1. abstractions should be meaningful, extracting code that makes sense only structurally is rarely a good thing. 2. when you see a need to use this abstraction once more and add a parameter, refactor once more. With more information you can achieve better structures, better abstractions. And this doesn't mean that you should not extract when you think you don't have enough information. That should be an iterative process, possibly infinite. :)
I hope I was able to express what I had in mind. Sometimes it is quite hard to do, especially for the things that seems obvious.
The main danger is when you bring two things together you are in a saying they are the same. It's like organising so the papers on your desk by color, at first this makes a ton of sense and brings a sense of Zen. However over time your boss informs you that he needs all the bills that were on your desk to be paid. This goes against your storage system, they are all mixed up! They seemed so similar however the more you learn they grow apart. This is no problem if you have the time to refactor your system to be more bill driven rather than color driven but often that abstraction becomes so ingrained it's very expensive to change. Waiting for more information is important.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've tried to write a comment here three times, and then deleted it. This one is the fourth. :) I'm not sure what's bothering me here. The idea of refactoring at the bottom is good. Smaller abstractions are perfect. But the idea of just leaving duplicated code makes me feel uneasy. And even that is not completely true. The idea of leaving duplicated code and feeling that it is ok, that's what I think is not good.
What I think would be slightly better, is to refactor anyway, even if it is duplicated "only" in two places, and there's a good chance that this code will be used more. I see two rules here: 1. abstractions should be meaningful, extracting code that makes sense only structurally is rarely a good thing. 2. when you see a need to use this abstraction once more and add a parameter, refactor once more. With more information you can achieve better structures, better abstractions. And this doesn't mean that you should not extract when you think you don't have enough information. That should be an iterative process, possibly infinite. :)
I hope I was able to express what I had in mind. Sometimes it is quite hard to do, especially for the things that seems obvious.
The main danger is when you bring two things together you are in a saying they are the same. It's like organising so the papers on your desk by color, at first this makes a ton of sense and brings a sense of Zen. However over time your boss informs you that he needs all the bills that were on your desk to be paid. This goes against your storage system, they are all mixed up! They seemed so similar however the more you learn they grow apart. This is no problem if you have the time to refactor your system to be more bill driven rather than color driven but often that abstraction becomes so ingrained it's very expensive to change. Waiting for more information is important.