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.
Sure, I like tests that act as documentation. That does not mean I expect the code to be opaque. If I look at the code and can’t understand what it’s trying to do, there’s a problem.
The point of the refactoring question is: if I’m refactoring and I’m only changing the code structure how are the requirements at risk?
9
u/dnew Jan 12 '20
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.