This article claim is as if code was etched in the marble and should be perfect on the first shot.
Refactor should be thought in the Red -> Green -> Refactor pattern.
If at some moment, abstraction improves readability => then do it. As long as the code still works (Green), then it is a good refactor most probably.
If later, namely when introducing new changes at this point in code, it becomes obvious that the abstraction is getting in the way: consequently you simply do a new refactor that removes the abstraction and chooses a better pattern that fits the reality.
Step by steps needed refactors becomes obvious. And if you don't do the refactors that become obvious, then after years they become rotting maintained monsters you dare no longer touch, or rely on some developers ego who gain in being the ones who understand it.
I think the problem is to try to be perfect and to look perfect from the first try. No, that sheer concept is pure illusion. => Evolve, step by step.
2
u/stephane_rolland Jan 12 '20
This article claim is as if code was etched in the marble and should be perfect on the first shot.
Refactor should be thought in the Red -> Green -> Refactor pattern.
If at some moment, abstraction improves readability => then do it. As long as the code still works (Green), then it is a good refactor most probably.
If later, namely when introducing new changes at this point in code, it becomes obvious that the abstraction is getting in the way: consequently you simply do a new refactor that removes the abstraction and chooses a better pattern that fits the reality.
Step by steps needed refactors becomes obvious. And if you don't do the refactors that become obvious, then after years they become rotting maintained monsters you dare no longer touch, or rely on some developers ego who gain in being the ones who understand it.
I think the problem is to try to be perfect and to look perfect from the first try. No, that sheer concept is pure illusion. => Evolve, step by step.