[BurningFrog]

> The key point is to keep refactoring “continuously“ to match our understanding of the domain, rather than just “adding features”.

This is also what I wanted to say.

One important part of that is that refactoring is a pretty difficult skill, and many programmers do not have it.

So... for those people, some other advice is probably better.

[karmakaze]

I wish this process was called 'factoring' and you had to be able to name the concept that was being isolated. Often 'refactoring' just means moving code around or isolating code for it's own sake. If a factor was properly isolated you shouldn't have to do that one again. Sometimes you choose different factors, but that's much less common.

[mntmoss]

"Factoring" is sometimes used in the Forth world, since code being factored into small words is of such eminence.

And it offers good lessons about what's worth factoring and how. Forth words that are just static answers and aliases are OK! They're lightweight, and the type signatures are informal anyway. "Doing Forth" means writing it to exactly the spec and not generalizing, so there's a kind of match of expectations of the environment to its most devoted users.

On the other hand, in most modern environments the implied goal is to generalize and piling on function arguments to do so is the common weapon of choice, even when it's of questionable value.

Lately I've cottoned on to CUE as a configuration language and the beauty of it lies in how generalization is achieved while resorting to a minimum of explicit branches and checks, instead doing so through defining the data specification around pattern matching and relying on a solver to find logical incoherencies.

I believe that is really the way forward for a lot of domains: Get away from defining the implementation as your starting point, define things instead in a system with provable qualities, and a lot of possibilities open up.

[dragonwriter]

> If a factor was properly isolated you shouldn't have to do that one again.

This assumes that later code changes don't undo/blur the factoring, which while ideal is not at all consistently the case in the real world.

Refactoring is a little over arrow of a name, because code hygiene is more than just isolating factors, but the “re” part is right because you are always aiming to remove infelicities that were actively added in previous coding.

[heymijo]

This lines up with a principle from the Toyota Production System (TPS) in manufacturing--reduce complexity.

In TPS, they found that a focus on reducing complexity leads to improvements in the metrics you'd want to measure: better quality, reduced costs, and customer satisfaction.