This is advocated in some popular books, but IMO it's the worst reason to break up a large function.
You end up with the same amount of code, but now you have to jump around. In most cases it also forces you to turn local variables into instance variables, globals, or pass state in parameters in order to carry state between the new functions, which further decreases readability.
You might as well add an "index" at the top of the large function and get the same readability benefits from doing it.
What should be done instead is trying to find code that can be abstracted without hurting readability. Most of the time in large functions there are mixed abstraction levels, such as business logic mixed with I/O, generic error handling that could be somewhere else, or object transformation that exists because of different libraries working differently.
When you automatically refactor into smaller functions you carry those problems into the small functions and you get code that is probably harder to follow, generates worse stack traces and only looks good in a shallow inspection.
Sounds a lot like programming in Haskell. Applying higher-order functions or condensing a parser into a oneliner just makes me feel smart in a way that generating a new Rails controller never does.
My personal theory is that a lot of Rust and Haskell (and many other "advanced" languages) usage is caused by people chasing that feeling. The publicly expounded benefits like memory and type safety are true, but the real reason is that people want to use the language for their own reasons and "I really like it" usually does not have enough weight in a business context.
You end up with the same amount of code, but now you have to jump around. In most cases it also forces you to turn local variables into instance variables, globals, or pass state in parameters in order to carry state between the new functions, which further decreases readability.
You might as well add an "index" at the top of the large function and get the same readability benefits from doing it.
What should be done instead is trying to find code that can be abstracted without hurting readability. Most of the time in large functions there are mixed abstraction levels, such as business logic mixed with I/O, generic error handling that could be somewhere else, or object transformation that exists because of different libraries working differently.
When you automatically refactor into smaller functions you carry those problems into the small functions and you get code that is probably harder to follow, generates worse stack traces and only looks good in a shallow inspection.