|
|
|
|
|
|
by cjfd
1620 days ago
|
|
|
If there is one single article about programming that I positively hate it is 'duplication is better than the wrong abstraction'. As the Jason Swett article points out the article seems to install a sort of fear of refactoring. If there is a 'wrong abstraction' nobody will every change it and now we are doomed to live with this wrong abstraction for all of eternity. The wrong abstraction can be turned into the right abstraction or can be undone if it is really not going anywhere. If that is what is happening at least people are trying to improve the code and if people try something it will eventually work. In many cases a bad code base is difficult to change because it is wrong in so many respects that it is difficult to tell where to start. If there is an attitude of refactoring and improvement things that are bad can be taken out quickly. Now, one should, of course not be stupid about removing duplication. If two functions just look vaguely similar but this is more of a coincidence than something that occurs because of the nature of the problem that these two functions are solving then they should absolutely not be one abstraction.... I suppose one might need to point that out to some developers but certainly not to ones who have been developers for some time and who actually have some talent as developers. |
|
|
Too many bad abstractions are how you quickly end up with that "Bad code base" that you believe is difficult to change - Things are wrong because they're tied together in ways that don't actually make sense, and changing code to support refactoring one use-case creates a wave of cascading changes to other places those abstractions are touched/consumed. If you miss one, or forget an edge case, or have a skimpy test suite - suddenly that refactoring you're so keen on is what's introducing new things that are "wrong" - because they shouldn't have been tied together but were, and you don't understand or remember all of the edge cases.
Basically - My rebuttal is this: It's very easy to refactor a codebase with duplication and introduce an abstraction for the current behavior. It's very HARD to refactor a codebase riddled with abstractions that shouldn't be there.
This means that by default - abstractions should only be introduced very carefully. Refactoring is fine, but you're paying more to refactor a bad abstraction than to refactor duplication. Good programmers understand that most of their value isn't in what their code looks like - it's in what it does for the users. Duplication can feel dirty, and it tends to trigger a "puzzle game" mentality in a lot of programmers, who want to fit the pieces together to make it pretty. AVOID THIS INSTINCT.