I don't think the author's point is truly contrarian. The author is a proponent of clarity in the code, and of the readability.
The deal here is that both versions are fairly readable, written by someone with intent to make it clear what the code should be doing. As a result the two versions are just examples of two expression styles, while the focus is on showing how the transition between these styles could be done.
What's worth underscoring here is the cohesiveness of stretches of code, such that their execution could be summarized by a descriptive function name.
Often in grand god-functions the contexts are so intertwined and mixed that it is hard to see cohesiveness in stretches of code.
Thus, the refactoring is very much a tool to creating such cohesiveness and proper logical sequencing.
Scooping out the code into separate function or commenting it out is more of a style judgement. Though putting the code into a function with a descriptive name indeed enforces this sort of analysis.
The differences are magnified when arbitrary test coverage metrics are imposed. The first example is easier to write tests for because all the conditionals are easier to scan. The second, green, example requires the test writer to follow multiple stack frames to write the test unless there’s some mocking and spying framework at hand.
The deal here is that both versions are fairly readable, written by someone with intent to make it clear what the code should be doing. As a result the two versions are just examples of two expression styles, while the focus is on showing how the transition between these styles could be done.
What's worth underscoring here is the cohesiveness of stretches of code, such that their execution could be summarized by a descriptive function name.
Often in grand god-functions the contexts are so intertwined and mixed that it is hard to see cohesiveness in stretches of code.
Thus, the refactoring is very much a tool to creating such cohesiveness and proper logical sequencing.
Scooping out the code into separate function or commenting it out is more of a style judgement. Though putting the code into a function with a descriptive name indeed enforces this sort of analysis.