Anatomical code metaphor. Where does muscle code

The code has muscles. True true. Do not believe? Look:



All the code that does the actual work: performs calculations, converts data, checks conditions, etc. - this is “meat”. "Muscles" of the program. The code that is responsible for structuring is “tendons”. This is where muscles are attached to bones. So that each individual muscle remains independent, and does not stick together in a shapeless stuffing. And then what "bones"? Bones - let it be the architecture of the program.
')


Here, for example, I found in my code a large incomprehensible piece, and begin to refactor it. I do all sorts of extraction methods, I add explanatory variables, somewhere I will apply the design pattern. The code continues to do the same, but it looks different. Some initial part of the code has not changed (it has only spread to different places), but a new code has been added, creating new, additional relationships between parts of the old code. What is this thing left and added?

To illustrate, I will quote Uncle Bob's code from his book - ta-dam! - “Clean Code”. At the beginning of the third chapter in Listing 3.1, he lists the testableHtml method, which he does not like because of his incomprehensibility. At the end of the chapter, in Listing 3.7, Robert leads the refactored code, which is much more understandable from his point of view. The code does the same thing, but is already grouped together as a whole class with 18 methods .

As for the clarity of this new code, I will go through another time, but for now I’ll just find out what changes have occurred.



In the picture - a new, refactored code. Here I clarified the fragments that survived refactoring in the same or almost unchanged form. Since the functionality remains the same, the “surviving” code (pale) is the “meat” that continues to do its work in the new code. Yeah, so, we do not look at the meat. What was added? A code has been added that in a new way organizes the flow of the old “meat”. Here it is, in full view: these are declarations and method calls, over which the old working code is now neatly distributed.

On the one hand, the new code got rid of duplication. In one place, its logic has become more straightforward: you see, in the old code , if the condition pageData.hasAttribute ("Test") is false, the lines ( op ) are executed one after the other:

buffer.append(pageData.getContent()); 

and then ( op ):

 pageData.setContent(buffer.toString()); 

There is an unnecessary assignment of the pageData variable to its own unchanged content; in the new code it is not.

On the other hand, many methods have been added with sometimes unclear names. The total amount of code has increased. The sequence of code execution ceased to correspond to the sequence of its recording (that is, signs of spaghetti appeared).

And yet, in my opinion, this is a step in the right direction, although in this particular case it is not entirely successful. Because the right direction is a balance point somewhere between the two extremes. It’s impossible to turn the code into unstructured mincemeat, but it’s also impossible to overdo it with the structure, so as not to get unreadable spaghetti. Some caterpillars are said to have up to 4,000 muscles, while a man has about 600 of them. And as for me, a man with his 600 is much prettier, so more does not always mean better. We will adhere to a reasonable balance.

I like to think that programs are live, although not all of them can reproduce on their own. Programs transform one complex something into another complex something. They communicate with people and with each other.

Sometimes I imagine myself to be Dr. Frankenstein, with a keyboard instead of a scalpel, puffing over the compilation of individual parts and reviving my next creation.
Who will be born this time? Choose one of three options:



PS: Muscles - they can not work without tendons. Give each muscle the right amount of tendons!