We just can’t have nice, clean terms with humans around.
I bet most developers hear the term “refactoring” used in context from other developers and assume it’s just a fancy word for changing your design. Same here. But no. It’s a more specific thing. And its value lies in that specificity.
“Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.” – Martin Fowler
You aren’t refactoring unless you preserve observable behavior. You might break the interface of a module for minute or two, but you should very quickly have a working system back, with no difference in observable behavior.
Renaming a method is refactoring.
Moving a method from one module to another one where it might make more sense: refactoring.
Taking several lines of code that perform a coherent action and extracting them into a method: refactoring.
Refactorings tend to be tiny moves. They’re made in the service of improving your design incrementally. They’re often made with the sense that you don’t know yet what will be a good design. But you think this small move is a step in the right direction.
Adding new behavior is never refactoring, but a little bit of strategic refactoring may be very helpful to do before you add a particular feature.
