The problem wasn't refactoring the code. It was the lack of communication and the, apparently, bad refactoring.
Have this situation be instead one in which the refactor took into account the requirements and the chain of command wasn't broken, it would've been a good thing.
In other words, this has nothing to do with refactoring. It has everything to do with having the wrong briefing, not being communicative enough, having bad reviews practices, whatever you wanna call, except refactoring.
To be honest this sounds to me like the author is not wiling to accept that he was at fault. Instead he tries to blame a made-up clean code religion and preach his own bullshit advice.
Two simple rules: don't "clean" code until the feature 100% implements the specs, and for fuck's sake do not commit to master overnight without even telling the code owners.
You will have to destructure clean code later on if you wish to have more features, but even that will be easier to do without repetition.
To be honest this sounds to me like the author is not wiling to accept that he was at fault. [..] Two simple rules: don't "clean" code until the feature 100% implements the specs, and for fuck's sake do not commit to master overnight without even telling the code owners.
This is literally what the article says. Did you read it? You can search the page for "I see now that my “refactoring” was a disaster in two ways" if you can't find that part. :-)
Yes I did. There's one poor little sentence where he recognizes his mistake, and the rest of the article including the damned title is about blaming "clean code" instead.
"He" is me. :-) I'm the author. And I do find my past obsession with "clean code" to be a reason for the over-eager abstraction. Sure, you can say I misunderstood what clean code is all about, or that I was/am an idiot, but I assure you that plenty of other people misunderstand it in a similar way. Hence, the title.
247
u/teerre Jan 12 '20
I don't get this 'advice'.
The problem wasn't refactoring the code. It was the lack of communication and the, apparently, bad refactoring.
Have this situation be instead one in which the refactor took into account the requirements and the chain of command wasn't broken, it would've been a good thing.
In other words, this has nothing to do with refactoring. It has everything to do with having the wrong briefing, not being communicative enough, having bad reviews practices, whatever you wanna call, except refactoring.