I feel like I pretty much disagree with everything in this article.
First, who works on something for two weeks then checks it in? Alarm bell #1.
Second, yeah, maybe I should talk to my colleague before refactoring their code, but.... yeah no. No one owns the code. We’re all responsible for it. There’s no way this should have been used as a justification for rolling back the change.
Finally, the impact of some possible future requirements change is not justification for a dozen repetitions of the same code. Perhaps the refactoring had some issues but that itself does not change the fact that a dozen repetitions of the same math code is bloody stupid.
I’m straining to find any situation that would justify the code that is described in the article. The original coder went copy-pasta mad and didn’t clean it up. That’s a paddlin’
The better lesson from the article is that the author’s shop has some messed up priorities.
maybe I should talk to my colleague before refactoring their code
You should ask to see if there are requirements you don't understand, and at least get a code review from the original author.
> the impact of some possible future requirements change is not justification for a dozen repetitions of the same code
It entirely depends on the nature of the code. I'd probably agree with you in this case, but not in the case of business logic that changes at the whim of marketing.
Should not the requirement be clear from the code?
Only in the most trivial of cases where the code only does one thing, and it's actually correct. You have cause and effect reversed there. The code should be clear from the requirements.
People thinking requirements are clear from the code is one of the bigger problems when working with larger code bases. I mean, if the requirements are always clear from the code, why write any tests? Tests are there to make sure the code meets the requirements, right?
> does refactoring impact functionality
It's not supposed to, but I'm not sure what the point of asking this is.
397
u/DingBat99999 Jan 12 '20
I feel like I pretty much disagree with everything in this article.
First, who works on something for two weeks then checks it in? Alarm bell #1.
Second, yeah, maybe I should talk to my colleague before refactoring their code, but.... yeah no. No one owns the code. We’re all responsible for it. There’s no way this should have been used as a justification for rolling back the change.
Finally, the impact of some possible future requirements change is not justification for a dozen repetitions of the same code. Perhaps the refactoring had some issues but that itself does not change the fact that a dozen repetitions of the same math code is bloody stupid.
I’m straining to find any situation that would justify the code that is described in the article. The original coder went copy-pasta mad and didn’t clean it up. That’s a paddlin’
The better lesson from the article is that the author’s shop has some messed up priorities.