Anatomical code metaphor. Where are the muscles in the code?

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

    All the code that does the real work: performs calculations, converts data, checks conditions, etc. - this is “meat”. Muscles of the program. The code that is responsible for structuring is the "tendon." That with which the muscles are attached to the bones. That is why each individual muscle remains independent, and does not stick together in formless stuffing. And then what are the “bones”? Bones - let it be the architecture of the program.

    For example, I found in my code a large obscure piece, and I begin to refactor it. I do all kinds of method extracts there, add explanatory variables, I’ll apply the design pattern somewhere. The code continues to do the same, but looks different. Some of the original part of the code has not changed (it just crawled to different places), but a new code was added that creates new, additional relationships between parts of the old code. What is it that is 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 provides the testableHtml methodwhich he does not like because of his incomprehensibility. At the end of the chapter, in Listing 3.7, Robert provides refactored code that is much more understandable from his point of view. The code does the same, but is already arranged as a whole class with 18 methods .

    Regarding the understandability of this new code, I will go over the next time, but for now I’ll just find out what changes have occurred.

    The picture shows a new, refactored code. Then I clarified fragments that survived refactoring in an unchanged or almost unchanged form. Since the functionality has remained the same, the "surviving" code (pale) is the "meat" that continues to do its job in the new code. Yeah, we don’t look at meat. What was added? A code has been added that organizes the flow of execution of the old "meat" in a new way. Here it is, at a glance: these are declarations and calls of methods by 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 became more straightforward: you see, in the old code , if the conditions for pageData.hasAttribute ("Test") are false, the lines ( op ) are executed one after another :


    and then ( op ):


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

    On the other hand, many methods have been added with sometimes obscure names. The total amount of code has increased. The sequence of code execution has ceased to correspond to the sequence of its writing (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 point of balance somewhere between two extremes. You can’t turn the code into unstructured mincemeat, but you can’t overdo it with the structure, so as not to get unreadable spaghetti. They say that some caterpillars can have up to 4,000 muscles, while a person has about 600 of them. And as for me, a person with 600 is much prettier, so more does not always mean better. We will maintain 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 present myself as a kind of doctor Frankenstein, with a keyboard instead of a scalpel, puffing over composing from separate parts and reviving my next creation.
    Who will be born this time? Choose one of three options: PS: Muscles - they cannot work without tendons. Give each muscle the right amount of tendons!

    Also popular now: