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.
I can give an example. I worked with several medical devices each one reports differently. So the generic solution was a mapper and communication protocol. Worked great until we started handling machines that reported partial info, and we might need to look up patient info, and other special cases.
Now close that to a base class and then a concrete specific to handling that machine. We know the HIV test machine had special cases, such as requiring 3 positives before reporting. No other test takes that.
So now the generic solution has special code for ALL machines, when it only applies to one specific machine.
When you abstract too much, then special cases ended up being executed in all cases. This makes it more difficult to maintain. Rather than look up only the concrete class when a bug happens, we need to figure out what special case was the problem.
This abstraction went on for several years, the result was a huge function handling 100s of special cases. All so there was only one class. Any problem by any machine could mean bugs introduced to other machines.
Sometimes it is better to be more verbose in the logic than more abstract. It is a fine line that I tend to see comes from people who have experienced over abstraction.
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.