The actual problem here isn't to refactor or not refactor. The mistake a lot of developers make, including here on HN is in thinking of it mechanistically, that

The actual problem here isn't to refactor or not refactor. The mistake a lot of developers make, including here on HN is in thinking of it mechanistically, that the code is just a bunch of operators and data and we've just gotta push it around the page some without really understanding it. That's how a lot of people interpret DRY, as an end in itself to be accomplished by pushing the symbols around and sweeping them up into something pretty. The most important thing isn't to apply these heuristics, but to understand the problem space in which your code operates before you lay down your abstractions. That's a difficult thing to do without domain knowledge, and in a lot of enterprises you will never get access to the kind of domain knowledge you need to refactor effectively unless you're the lead or in management. To the extent that your code is a series of statements about how the system behaves in response to a particular data input it's easy to read and documents itself. And to the extent that your data structures and statements resemble statements that a domain expert might make(move gantry 30 meters to the left, then drop the crane) they become easy to change in response to changing requirements. Domain knowledge tells you what the fixed elements of the problem space are(is it always a gantry? Does the gantry move in any directions other than left? What does it mean to drop the crane and do we do it different ways?). That informs how you structure your code and what the most clear factoring is. It will not always be the smallest refactoring.