Once you completely remove the old abstraction you can start anew, re-isolating duplication and re-extracting abstractions.
#THE DUPLICATE FINDER INSTRUCTIONS CODE#
When you rewind decisions in this way, it's common to find that although each caller ostensibly invoked a shared abstraction, the code they were running was fairly unique. This removes both the abstraction and the conditionals, and reduces each caller to only the code it needs. Delete the bits that aren't needed for this particular caller.Within each caller, use the parameters being passed to determine the subset of the inlined code that this specific caller executes.Re-introduce duplication by inlining the abstracted code back into every caller.When dealing with the wrong abstraction, the fastest way forward is back. If you find yourself in this situation, resist being driven by sunk costs. It is hard to understand and easy to break. The code no longer represents a single, common abstraction, but has instead become a condition-laden procedure which interleaves a number of vaguely associated ideas. When you appear in this story in step 8 above, this pressure may compel you to proceed forward, that is, to implement the new requirement by changing the existing code. It would be a sin to let all that effort go to waste." It's as if our unconscious tell us "Goodness, that's so confusing, it must have taken ages to get right. the deeper the investment in creating it, the more we feel pressure to retain it (the " sunk cost fallacy"). And, unfortunately, the sad truth is that the more complicated and incomprehensible the code, i.e. We know that code represents effort expended, and we are very motivated to preserve the value of this effort. Its very presence argues that it is both correct and necessary. You appear in the story about here, and your life takes a dramatic turn for the worse.Įxisting code exerts a powerful influence. Loop until code becomes incomprehensible.
What was once a universal abstraction now behaves differently for different cases. Programmer B feels honor-bound to retain the existing abstraction, but since isn't exactly the same for every case, they alter the code to take a parameter, and then add logic to conditionally do the right thing based on the value of that parameter. Programmer B gets tasked to implement this requirement. Programmer A trots happily away.Ī new requirement appears for which the current abstraction is almost perfect. Programmer A replaces the duplication with the new abstraction.Īh, the code is perfect. It could be a new method, or perhaps even a new class. Programmer A extracts duplication and gives it a name. I started asking questions and came to see the following pattern: The strength of the reaction made me realize just how widespread and intractable the "wrong abstraction" problem is. This, a million times this! " "Duplication is far cheaper than the wrong abstraction" /3qMI0waqWb"- 41 shades of blue March 7, 2014 A few folks suggested that I had lost my mind, but many more expressed sentiments along the lines of: This small section of a much bigger talk invoked a surprisingly strong reaction. Prefer duplication over the wrong abstraction I've been thinking about the consequences of the "wrong abstraction." My RailsConf 2014 " all the little things" talk included a section where I asserted:ĭuplication is far cheaper than the wrong abstraction _I originally wrote the following for my Chainline Newsletter, but I continue to get tweets about this idea, so I'm re-publishing the article here on my blog.
0 kommentar(er)
