“Single-threaded Programmer”
All the following fiction based on real events.
Not being a master of writing notes, I tried “with the heat of the heat” to set it up yesterday. But it was easy and affordable to build thoughts in a well-groomed order “without a trace” did not work out.
Moreover, from personal experience, it turned out that the described approach, although it seems to me very simple at first glance, is not statistically so. The well-known saying that “simple things, they are the most complex” turns out to be true in this case.
')
The “practical” application of this approach requires effort and painstaking work on oneself, until it becomes an unconditional reflex, until the allowable “inaccuracy” is noticeable even before it is accomplished.
Therefore, having stumbled over the same problem “nadtsaty” times, and “nadtsaty” times watching its identical solution, I believe that the presentation of this “approach” in writing will help me even more firmly fix it as a “skill”.
In this connection, by publishing this note here, I expect that the second "shot hare" may be helping someone else to get rid of such situations.
UPD3 thanks dimka_ben : "single-threaded" refers to the peculiarity of thinking of a particular individual, when at one time he can think only about one thing.
So, there are two programmers. Normal guys know a lot, work with dignity.
UPD1 : to the advice from the bachin comment:
#define Nikita "programmer number one"
#define Denis "Programmer Number Two"
Both deal with UI, both write browser code in javascript. Both understand each other’s code, and both correct it without serious problems.
But at the same time, the situation is repeated over and over again: if Denis corrects Nikita's code, then he never gets it the first time. Nikita always corrects Denis’s code immediately, without delays and problems.
Here one would think that Denis is simply "worse." But in reality, this is not quite the case; they are simply “different”, and faced with different things. And now they are doing the “same thing”.
And then came the moment when Nikita went on vacation. Naturally, the situation soon worsened, and Denis had to edit, though familiar, but still “alien” code.
He reworked it three times. Almost a whole working day with thirty lines of code. Given that this code was familiar to him and had not changed significantly for several months.
And it was necessary, it was not even a correction, but a minor refinement, the output of a message in the case of one of the three possible Use Case.
When he brought out the “Message” for the first time, a bug appeared in Jira that two other Use Cases had fallen off. He corrected the error, but two bugs immediately appeared in Jira that the necessary “Message” no longer exists and the third Case does not work. As a result, this was repeated several times, a total of 10 bugs accumulated.
Since this situation was already more than usual, I decided to recall when and under what specific conditions it was repeated.
It turned out that this always happens in approximately the same situation, with almost unchanged given:
The last time Denis dug in a situation of three buttons:
Nikita placed a single handler on all three buttons, i.e. All three buttons "converge" in one method. It turned out three different combinations that perform similar, but still slightly different algorithmic sequences. The method also involved a couple of other sequences available through the “statuses” by IF. Then Denis took even more time, since the total number of Use Case in one method was 7.
Trying to understand why Nikita wrote such a code without errors, and Denis could not fix it later, despite the fact that there are no constructions from the category of “dynamics of external spheres”, I came to the conclusion that the guys differ within some basic contradiction .
Nikita worked half-life with strongly typed programming languages that required compilation before running the application.
Denis worked most with scripting languages with weak typing, we can say that all my life I used JavaScript as the main language.
Nikita understood OOP at the level of method redefinition by means of a different set of input variables. Denis also implemented prototyping inheritance without any problems.
Nikita worked with multithreaded applications. Denis was going to start to deal with the implementation of multithreading in the framework of Node.JS.
The result was an interesting picture:
That is, Denis “immediately” does not perceive the situation at all when several different user behaviors converge into the same algorithm.
Having understood this “starting point” in differences, I decided to look at Denis’s code more closely, all of a sudden he doesn’t use “general” methods at all and does not write “shared” code.
It turned out that unlike Nikita, he writes “shared code” differently. Of course, he brings out what is repeated in separate methods, but what we have already called the “user’s entry point to the Use Case” is always implemented by one separate method.
Then I asked him: "Why are you doing this?"
The answer shocked me: “So I will never forget that there is something else working here, because nothing more is described here. ”
That is, as soon as he came across a situation in which the second “input” Use Case appeared within the framework of one method, he divided the code into two, and carried out the “duplicate” parts into separate accompanying methods. And he usually did it even in the process of thinking about the algorithm and analyzing what he was going to write.
Thus, it turned out that in the “debugger” there can be only one, the only realization of the processing of actions from the user.
And he never came across the fact that he might forget or miss something, because there was simply nothing to forget.
At that moment, when he began to correct Nikita's “shared code”, his “single-threaded” approach broke down, and he needed extra time to remember that there could be a completely different way of presenting thoughts.
And then I decided to see if Nikita had such situations. It turned out that, oddly enough, but - there is. He just coped with them immediately after the appearance of the corresponding bug. That is, by virtue of habit, he simply remembered that several Use Case might converge here, but he was not immune from mistakes either.
Then I analyzed the “bugs” of Denis and found out that there are no such bugs in his code at all, i.e. it never returns to what is already working, until you need to make changes. No, he had mistakes as well, but they were not related to the fact that the entry point to different Use Case was the same method, since he just didn't have that code.
It turned out that in similar situations Denis spends much more time on correcting Nikita's approaches than Nikita himself, but Denis with his own code does not have such problems at all.
There remained the last question - why Nikita also falls into such situations. Trying to understand it, I thought about the language itself. JavaScript is single threaded. And Denis always thinks in one stream and is “debugged” too, only in “one stream”. Nikita thinks about many situations at once, but even he sometimes makes mistakes when “mixing Use Cases”.
Knowing this feature of his, Denis tries to make it so that there is nothing to debug.
Nikita just writes the code, because he seems to have nothing to think about.
I do not know what to call this approach and where it came from. Maybe this is one of the principles of KISS, maybe it is something from graceful degradation, maybe it is part of the unix way (one action, but “good”).
In the wiki, by the way, there is something like en.wikipedia.org/wiki/Separation_of_concerns , but I'm not sure if this is straightforward.
But in any case, I like that at “number two” only one thing can break at one moment, and I don’t like that “number one”, if it breaks at all, then all at once.
UPD2 : thanks zloddey , maybe this is SRP
Not being a master of writing notes, I tried “with the heat of the heat” to set it up yesterday. But it was easy and affordable to build thoughts in a well-groomed order “without a trace” did not work out.
Moreover, from personal experience, it turned out that the described approach, although it seems to me very simple at first glance, is not statistically so. The well-known saying that “simple things, they are the most complex” turns out to be true in this case.
')
The “practical” application of this approach requires effort and painstaking work on oneself, until it becomes an unconditional reflex, until the allowable “inaccuracy” is noticeable even before it is accomplished.
Therefore, having stumbled over the same problem “nadtsaty” times, and “nadtsaty” times watching its identical solution, I believe that the presentation of this “approach” in writing will help me even more firmly fix it as a “skill”.
In this connection, by publishing this note here, I expect that the second "shot hare" may be helping someone else to get rid of such situations.
UPD3 thanks dimka_ben : "single-threaded" refers to the peculiarity of thinking of a particular individual, when at one time he can think only about one thing.
So, there are two programmers. Normal guys know a lot, work with dignity.
UPD1 : to the advice from the bachin comment:
#define Nikita "programmer number one"
#define Denis "Programmer Number Two"
Both deal with UI, both write browser code in javascript. Both understand each other’s code, and both correct it without serious problems.
But at the same time, the situation is repeated over and over again: if Denis corrects Nikita's code, then he never gets it the first time. Nikita always corrects Denis’s code immediately, without delays and problems.
Here one would think that Denis is simply "worse." But in reality, this is not quite the case; they are simply “different”, and faced with different things. And now they are doing the “same thing”.
And then came the moment when Nikita went on vacation. Naturally, the situation soon worsened, and Denis had to edit, though familiar, but still “alien” code.
He reworked it three times. Almost a whole working day with thirty lines of code. Given that this code was familiar to him and had not changed significantly for several months.
And it was necessary, it was not even a correction, but a minor refinement, the output of a message in the case of one of the three possible Use Case.
When he brought out the “Message” for the first time, a bug appeared in Jira that two other Use Cases had fallen off. He corrected the error, but two bugs immediately appeared in Jira that the necessary “Message” no longer exists and the third Case does not work. As a result, this was repeated several times, a total of 10 bugs accumulated.
Since this situation was already more than usual, I decided to recall when and under what specific conditions it was repeated.
It turned out that this always happens in approximately the same situation, with almost unchanged given:
- UI processes the user’s events (actions): pressing the button, choosing from the list, in general - “interactive”.
- Usually the situation happens in a very simple, one can even say “elementary” algorithm, when it seems that it can be corrected in five minutes.
- In processing different Use Case, one method or one function is used. Those. the same “entry point into the algorithm” but from a different sequence of user actions. Often, even from different screens.
The last time Denis dug in a situation of three buttons:
- “Save” and “Save and Create More” on the “Create” screen of the recording,
- “Save” on the “Edit” screen.
Nikita placed a single handler on all three buttons, i.e. All three buttons "converge" in one method. It turned out three different combinations that perform similar, but still slightly different algorithmic sequences. The method also involved a couple of other sequences available through the “statuses” by IF. Then Denis took even more time, since the total number of Use Case in one method was 7.
Trying to understand why Nikita wrote such a code without errors, and Denis could not fix it later, despite the fact that there are no constructions from the category of “dynamics of external spheres”, I came to the conclusion that the guys differ within some basic contradiction .
Nikita worked half-life with strongly typed programming languages that required compilation before running the application.
Denis worked most with scripting languages with weak typing, we can say that all my life I used JavaScript as the main language.
Nikita understood OOP at the level of method redefinition by means of a different set of input variables. Denis also implemented prototyping inheritance without any problems.
Nikita worked with multithreaded applications. Denis was going to start to deal with the implementation of multithreading in the framework of Node.JS.
The result was an interesting picture:
- Nikita, when debugging, may think that this code will work in different Use Case.
- Denis remembers that here a few Use Case only after receiving a pack of bugs.
That is, Denis “immediately” does not perceive the situation at all when several different user behaviors converge into the same algorithm.
Having understood this “starting point” in differences, I decided to look at Denis’s code more closely, all of a sudden he doesn’t use “general” methods at all and does not write “shared” code.
It turned out that unlike Nikita, he writes “shared code” differently. Of course, he brings out what is repeated in separate methods, but what we have already called the “user’s entry point to the Use Case” is always implemented by one separate method.
Then I asked him: "Why are you doing this?"
The answer shocked me: “So I will never forget that there is something else working here, because nothing more is described here. ”
That is, as soon as he came across a situation in which the second “input” Use Case appeared within the framework of one method, he divided the code into two, and carried out the “duplicate” parts into separate accompanying methods. And he usually did it even in the process of thinking about the algorithm and analyzing what he was going to write.
Thus, it turned out that in the “debugger” there can be only one, the only realization of the processing of actions from the user.
And he never came across the fact that he might forget or miss something, because there was simply nothing to forget.
At that moment, when he began to correct Nikita's “shared code”, his “single-threaded” approach broke down, and he needed extra time to remember that there could be a completely different way of presenting thoughts.
And then I decided to see if Nikita had such situations. It turned out that, oddly enough, but - there is. He just coped with them immediately after the appearance of the corresponding bug. That is, by virtue of habit, he simply remembered that several Use Case might converge here, but he was not immune from mistakes either.
Then I analyzed the “bugs” of Denis and found out that there are no such bugs in his code at all, i.e. it never returns to what is already working, until you need to make changes. No, he had mistakes as well, but they were not related to the fact that the entry point to different Use Case was the same method, since he just didn't have that code.
It turned out that in similar situations Denis spends much more time on correcting Nikita's approaches than Nikita himself, but Denis with his own code does not have such problems at all.
There remained the last question - why Nikita also falls into such situations. Trying to understand it, I thought about the language itself. JavaScript is single threaded. And Denis always thinks in one stream and is “debugged” too, only in “one stream”. Nikita thinks about many situations at once, but even he sometimes makes mistakes when “mixing Use Cases”.
Knowing this feature of his, Denis tries to make it so that there is nothing to debug.
Nikita just writes the code, because he seems to have nothing to think about.
I do not know what to call this approach and where it came from. Maybe this is one of the principles of KISS, maybe it is something from graceful degradation, maybe it is part of the unix way (one action, but “good”).
In the wiki, by the way, there is something like en.wikipedia.org/wiki/Separation_of_concerns , but I'm not sure if this is straightforward.
But in any case, I like that at “number two” only one thing can break at one moment, and I don’t like that “number one”, if it breaks at all, then all at once.
UPD2 : thanks zloddey , maybe this is SRP
Source: https://habr.com/ru/post/181095/
All Articles