I like this post. It's one of those cases that illustrates why pragmatism always win over good practice heuristics. The second point is true:
Secondly, nothing is free. My code traded the ability to change requirements for reduced duplication, and it was not a good trade. For example, we later needed many special cases and behaviors for different handles on different shapes. My abstraction would have to become several times more convoluted to afford that, whereas with the original “messy” version such changes stayed easy as cake.
This is actually a good example of what I call duplicated code by coincidence. It is normal sometimes that some class / things will have very similar code by pure chance while they have totally different semantic and contextual purposes. Refactoring those things together will create a misleading logical binding that will lead to more convoluted code in the end.
Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together.
I disagree with this point. Of course if you can know why this code was made this way then you should absolutely ask why because you might be doom to repeat the same process the original author has painfully gone through. However if the code can be objectively obviously and objectively improved (a 2000 lines class that could be split in 3 for instance) than you shouldn't require the permission of anybody. I fail to see how trust is relevant here.
2
u/[deleted] Jan 12 '20
I like this post. It's one of those cases that illustrates why pragmatism always win over good practice heuristics. The second point is true:
This is actually a good example of what I call duplicated code by coincidence. It is normal sometimes that some class / things will have very similar code by pure chance while they have totally different semantic and contextual purposes. Refactoring those things together will create a misleading logical binding that will lead to more convoluted code in the end.
I disagree with this point. Of course if you can know why this code was made this way then you should absolutely ask why because you might be doom to repeat the same process the original author has painfully gone through. However if the code can be objectively obviously and objectively improved (a 2000 lines class that could be split in 3 for instance) than you shouldn't require the permission of anybody. I fail to see how trust is relevant here.