Right after writing code. It's in the phrase red-green-refactor. Said another way that's: figure out what to do, then do it as naively as possible, then figure out how to make it more readable/more modular/more extendable/more reusable/more performant.
Right before writing code. I like to say, "Make it easy; then make the change". Often more junior devs will take a requirement and charge headlong into making it; but it would have been easier and faster if they took a step back and adjusted their helpers/utilities/services/framework to make incorporating the new feature simpler.
One should stop refactoring once the benefits either don't outweigh the costs or become too hypothetical/far in the future.
Thanks for the response.
The idea of when to stop refactoring was helpful.
I have seen developers of different experience level, refactor differently.
Hence code review feedbacks too vary.
I have seen the "really old developers" have achieved the right balance/zen of refactoring.
The dangerous ones are intermediate ones who over-engineer because they have recently came accross the topics of refactoring and design patterns and overdo it
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think there's two times to refactor:
Right after writing code. It's in the phrase
red-green-refactor. Said another way that's: figure out what to do, then do it as naively as possible, then figure out how to make it more readable/more modular/more extendable/more reusable/more performant.Right before writing code. I like to say, "Make it easy; then make the change". Often more junior devs will take a requirement and charge headlong into making it; but it would have been easier and faster if they took a step back and adjusted their helpers/utilities/services/framework to make incorporating the new feature simpler.
One should stop refactoring once the benefits either don't outweigh the costs or become too hypothetical/far in the future.
Thanks for the response.
The idea of when to stop refactoring was helpful.
I have seen developers of different experience level, refactor differently.
Hence code review feedbacks too vary.
I have seen the "really old developers" have achieved the right balance/zen of refactoring.
The dangerous ones are intermediate ones who over-engineer because they have recently came accross the topics of refactoring and design patterns and overdo it