x^2 + x z + y x + y z
then you notice that you can express the same polynomial as:
(x + y)*(x + z)
It's still the same polynomial, but you "separated concerns", turning it into a product of two simpler factors.
Similar ideas apply to sets of tuples. Perhaps you were given
{(1, 1), (1, 4), (2, 1), (2, 4), (3, 1), (3, 4)}
and you notice that this can be expressed more simply as the Cartesian product:
{1, 2, 3} x {1, 4}
Again, a literal factoring. You can imagine how variations of this idea would apply to database tables and data structures.
That's where I think the word "refactor" comes from.
Nice to learn where the word originates from. Often the meaning of words change over time. E.g. today no horses need involved in bootstrapping.
Refactoring does not change the external behavior. If you can't change the internal behavior, then you can't reduce complexity.
So with that in mind...
- changing implicit caching => refactoring
- changing implicit timeouts => refactoring
- changing explicit caching => more than refactoring
- changing explicit timeouts => more than refactoring
Because the word external implies conceptual boundaries, I would personally also distinguish refactoring by levels:
- system design
- service design
- program design
- component design
- module design
- function design
...where this blog post only talks about the latter two.
If something changed, it's not a refactor. It's a change.
Like in the example where the caching was removed: NOT a refactor.
Ore where the timeouts for the requests were changed: NOT a refactor.
The definition of refactor: change the structure of the code without altering the behavior.
It's like saying a crash is a bad landing.