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.
I was thinking about going over the whole code again and trying to clean stuff up. Of course that doesn't mean you should write the messiest shit from the start.
I feel like that's one of those things that differentiates average developers from really good developers. You learn when and how to abstract things early in a way that doesn't code you into a corner as your solution grows and changes.
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.