3 ms·

I have technical leads tell me to copy paste code all the time instead of making better abstractions. It drives me slightly mad.

Pfhreak 10y ago
I've generally followed the rule of thumb: If you're doing the same thing in two places, ok, if you are doing the same thing in three places, refactor. Let's me get away with copy pasting while I'm quickly prototyping something out, but reminds me that I need to clean it up before I try to iterate again. Plus, it's unlikely that I'll hit the right abstraction on the first or second time I see a problem. Better to wait until I've seen it three times before refactor.
- wry_discontent 10y ago
  I'll forget to do it if I wait until the third time. I can't keep track of everything, you know.
  - ricksplat 10y ago
    My worry in that case though is you could end up with a whole heap of unnecessary abstractions which can make reading by a third party (or yourself even in 6 months) a little more tricky. I'm seen so many functions of the like of `Util.checkNull(String str)` where simply `str == null || str.empty()` would have done.
- cema 10y ago
  I am of a different persuasion. Even if you are doing one thing, but it is indeed a thing, refactor it as a separate abstraction. You will end up with a better set of building blocks.
  - ricksplat 10y ago
    all the better for maintaining a clean suite of unit-tests too!
    - cema 10y ago
      True.
- ricksplat 10y ago
  > while I'm quickly prototyping I think any kind of skullduggery is fair game at this stage when you just want to "get it to work". For me the rule of thumb to go beyond this point is the commit (or push if I'm using git). After that point you lose control of it. Other people see it, and start to poke around and change things and retrospectively delivering on your good intentions to provide "done" code becomes more difficult. Always do a personal review before letting your code out of it's box. Of course if you can find somebody who's interested get their feedback too ...

Pfhreak 10y ago

I've generally followed the rule of thumb: If you're doing the same thing in two places, ok, if you are doing the same thing in three places, refactor. Let's me get away with copy pasting while I'm quickly prototyping something out, but reminds me that I need to clean it up before I try to iterate again. Plus, it's unlikely that I'll hit the right abstraction on the first or second time I see a problem. Better to wait until I've seen it three times before refactor.

wry_discontent 10y ago
I'll forget to do it if I wait until the third time. I can't keep track of everything, you know.
- ricksplat 10y ago
  My worry in that case though is you could end up with a whole heap of unnecessary abstractions which can make reading by a third party (or yourself even in 6 months) a little more tricky. I'm seen so many functions of the like of `Util.checkNull(String str)` where simply `str == null || str.empty()` would have done.
cema 10y ago
I am of a different persuasion. Even if you are doing one thing, but it is indeed a thing, refactor it as a separate abstraction. You will end up with a better set of building blocks.
- ricksplat 10y ago
  all the better for maintaining a clean suite of unit-tests too!
  - cema 10y ago
    True.
ricksplat 10y ago
> while I'm quickly prototyping I think any kind of skullduggery is fair game at this stage when you just want to "get it to work". For me the rule of thumb to go beyond this point is the commit (or push if I'm using git). After that point you lose control of it. Other people see it, and start to poke around and change things and retrospectively delivering on your good intentions to provide "done" code becomes more difficult. Always do a personal review before letting your code out of it's box. Of course if you can find somebody who's interested get their feedback too ...