>
Those abstractions were created by someone for some reasons.Yes. But there is no optimal, best single abstraction - the best abstraction is always for a specific purpose you're looking at the code in question. Same code, same programmer, two different tasks - each may command a code structure opposite of the other.
The core problem is that we insist on working with a single-source-of-truth, plaintext representation - and that is not even remotely sufficient to express everything, every cross-cutting concern, in a readable way, at the same time. Inlining is a perfect example, because "few big functions" vs. "lots of small functions" is one of those holy wars that will not end, because the actual answer is "whichever works best, for you, at this moment".
A bluntly-put corollary:
> Refactoring should be process that involves intellectual creativity, involves deeply understanding the intricacy of dependencies and references, not mechanically expanding functions and call it done.
The sad thing is, all that creativity and exertion of mind is wasted work. The more you refactor your code for your current purpose, the harder it will be for you (or someone else) to work with the code for for a different, cross-cutting purpose. Past some point, we're just overfitting the medium of single, flat, plaintext representation.
A tool like this `clang-expand` is an example of a small part of a solution - ideally, you should be able to trivially do those transformations whenever you need, on whatever code you need, mostly for reading but also for writing. As in, inline a bunch of functions, filter out noise, make your changes, and have those changes propagate to where they should in "canonical representation" - the raw source code, which you don't generally look at, any more than you look at object files your compiler produces today.