My cat is about "perfect code"
Epic epigraph:
"Patterns you may not know
but the management must know! ”
Anyone familiar with Gödel's theory of uncertainty (which has received the not quite accurate name “of incompleteness”) understands that all (sufficiently) complex systems experience fundamental difficulties in self-knowledge and self-description at a certain level of depth and detail. At once I will clarify: I am NOT saying that there is a direct connection between the theory of the aforementioned G. and the “eternal” (precisely in quotes!) Problems of the PLO. But I, nevertheless, claim that the problems of the “perfect code” are not objectively solvable. Not at all ever, but exactly until the moment when we finally go beyond the limits of the PLO itself - and look at it from a height of an even more complex system. “The big is seen at a distance”!
So here. Rejoice, people and beasts! I have a suitable "height"! It is called “ Enough General Management Theory ” (hereinafter referred to as “DUT”). Since this text should neither popularize nor advertise the DOTA, I will say almost nothing about it. Like all truly life-affirming ideas, it “speaks and shows” for itself. But it’s impossible not to mention the DOTA at all either - after all, should I present my ideological (and terminological, if anything) standard?
Creating a program is a management process (an enthusiastic “oh!” In the auditorium!). A multilevel, very complex organization - but still it is management. Unfortunately, not many people think that management is a thing that exists objectively (for example, clouds in the sky or space-time relativity). The latter (objectivity) and determines the existence of such sciences and pseudoscience as management or meteorology. In short, the point is that there is something in common between programming exactly as a process of managing something quite definite and controlling anything else (but also concrete, one way or another defined). Like the call base. The abundance of words like “something”, “something” indicates that we have climbed to a very high level of abstractions - so high that our language barely copes with the explanation. So, we have got where it is necessary: from here we will begin (we will only begin!) To understand what “perfect code” is.
')
So, management is when, as a result of a manager's actions, an object / process has moved from one state (which, for whatever reason, this manager did not suit, otherwise the need for management would not arise!) To another state. And from this follows a vital conclusion: the right approach to management literally anything necessarily requires that even before the start of active actions, the manager has a fairly clear idea of his goals - that is, about the state in which, at the end of the day, that object / process should turn out to be, which it still intends to control. If we are talking about a developer, then until he has a more or less clear (and sufficiently detailed, interrelated) picture of the product in his head, he should not write a single line of code. Please note: this is about the image of the final product itself , and not the code behind it; code is the means by which the intention is realized. And one more important clarification - here the term “final product” means nothing else but the final product. In other words, the final product is the final product, not the intermediate version. Just in case, one more time: “the final product” is what happens at the end - that is, at the very end. And the end is, in turn, not the middle, not 2/3 or even 49/50. Well, you get the idea ...
Now turn on the conscience and honestly answer the question - how often do you follow this simple and self-evident principle of management in general in your projects? Do you know why this practice is inherent only to the elect? Yes, because it is a VERY "intelligence-capacious" task - to draw in your head all the details of the future project. Especially if it promises to be huge and with unpredictable turns halfway through. But the project’s fault is not in it. This means only one thing: this management task does not match your (or mine, or his, or her) management skills. This is not about programming as such; not at all that the “Peter” object of the “DotNetDevelopers” class does not know how string x + = string y differs from StringBuilder x.Append (y). The problem is just different - I call it "managerial impotence." And it is much more common (and dangerous) than just impotence! ..
Che is there now in fashion in any weather? Patterns? Honestly, I am not an expert on patterns, but even my acquaintance with them (I read the works of the gang of four and even tasted it!) Is enough to say with almost complete certainty: these patterns of yours do not solve the problem. Maximum - cover up. And as a rule, they simply smear them - evenly over all the surfaces where they passed (more often they crawled) the next zombie from “God Save the Patterns”. To solve this problem at the level of new “stuff” of compilers or frameworks is impossible. Not that level.
Well, take the pens in your hands and write it down: NO AN EXCELLENT CODE IS EXISTING. But there is a code that solves a specific management problem completely . Therefore, to consider the code separately from the task is the same nonsense how to treat the cell separately from the microscope. Rather, "House-2" will end than this happens! Therefore, if the peculiarity of your task is such that you absolutely do not care if the graphical interface responds or is hopelessly busy with some kind of crazy loop, then your single-threaded code is smart (of course, provided that the loop does not let us down). And if communication with the user is a priority, then you are still another .Net-squalor!
The only thing that makes sense to talk essentially on the topic of a perfect code is the amount of effort that has to be spent on its creation. Here is async / await, shpasiba clever uncles from Microsoft, cool saves time. Therefore (all other things being equal) the code based on async should be recognized objectively better than BeginXXX / EndXXX. But it was understandable even mentally retarded. And not at all to this conclusion, I wanted to bring.
The problem of bad projects is not in bad programmers, but in bad managers who ineptly manage the process of creating local code / application as a whole . And this problem should be solved at an appropriate level (which, as you probably did NOT understand, is much, much higher than any compilers there - with all due respect to the latter).
I have one little idea about solving the problem. It would be nice to sip "weigh", which would be used as a kind of test for the ability to manage this particular project. It would work like this: I click “create a new project”. Next, a tricky algorithm is launched, in the course of which an array of parameters is created, which will describe what in the aforementioned DOTA is called the “Target Vector” and the “Current State Vector”. And then the stage at which you all break off is to indicate the SPECIFIC values of the created parameters for the final state to which I am trying to lead this object / process (this will be my goal). If I am not capable of this (and I am still a wicked one!), Then this means that at the moment I do not have a clear enough picture of what is happening, I can’t set a sufficiently definite goal, and therefore my control (i.e. my code and the project as a whole) will smack yourself guess what. Of course, it is possible to spice up this business with patterns, but then it will turn out like in that joke - “as if someone had shit under the tree”.
But the initialization of the “vector of goals” (in terms of the same DOTA) is not the end of the quest. Further more. Moving from the final state to the initial state, I must divide the management process into a sequence of steps. Each step is a set of states in which the object / process could be at the appropriate stage of its implementation. In fact, we are talking about creating a grid of states (“matrix of possible transitions” (c) DOTA), within which the project will be carried out. Essentially, each state is described by the same set of parameters - only they take on different values. This is where trash managers from God will separate from other husks (regardless of certificates, age, salary, and self-importance). And if someone is capable of vital, convincingly to bring the project from the final state to the initial state - to him and the patterns in hand!
"Patterns you may not know
but the management must know! ”
"The big is seen at a distance"
Anyone familiar with Gödel's theory of uncertainty (which has received the not quite accurate name “of incompleteness”) understands that all (sufficiently) complex systems experience fundamental difficulties in self-knowledge and self-description at a certain level of depth and detail. At once I will clarify: I am NOT saying that there is a direct connection between the theory of the aforementioned G. and the “eternal” (precisely in quotes!) Problems of the PLO. But I, nevertheless, claim that the problems of the “perfect code” are not objectively solvable. Not at all ever, but exactly until the moment when we finally go beyond the limits of the PLO itself - and look at it from a height of an even more complex system. “The big is seen at a distance”!
Photo of my cat
So here. Rejoice, people and beasts! I have a suitable "height"! It is called “ Enough General Management Theory ” (hereinafter referred to as “DUT”). Since this text should neither popularize nor advertise the DOTA, I will say almost nothing about it. Like all truly life-affirming ideas, it “speaks and shows” for itself. But it’s impossible not to mention the DOTA at all either - after all, should I present my ideological (and terminological, if anything) standard?
Creating a program is a management process (an enthusiastic “oh!” In the auditorium!). A multilevel, very complex organization - but still it is management. Unfortunately, not many people think that management is a thing that exists objectively (for example, clouds in the sky or space-time relativity). The latter (objectivity) and determines the existence of such sciences and pseudoscience as management or meteorology. In short, the point is that there is something in common between programming exactly as a process of managing something quite definite and controlling anything else (but also concrete, one way or another defined). Like the call base. The abundance of words like “something”, “something” indicates that we have climbed to a very high level of abstractions - so high that our language barely copes with the explanation. So, we have got where it is necessary: from here we will begin (we will only begin!) To understand what “perfect code” is.
')
"No manager will not enter"
So, management is when, as a result of a manager's actions, an object / process has moved from one state (which, for whatever reason, this manager did not suit, otherwise the need for management would not arise!) To another state. And from this follows a vital conclusion: the right approach to management literally anything necessarily requires that even before the start of active actions, the manager has a fairly clear idea of his goals - that is, about the state in which, at the end of the day, that object / process should turn out to be, which it still intends to control. If we are talking about a developer, then until he has a more or less clear (and sufficiently detailed, interrelated) picture of the product in his head, he should not write a single line of code. Please note: this is about the image of the final product itself , and not the code behind it; code is the means by which the intention is realized. And one more important clarification - here the term “final product” means nothing else but the final product. In other words, the final product is the final product, not the intermediate version. Just in case, one more time: “the final product” is what happens at the end - that is, at the very end. And the end is, in turn, not the middle, not 2/3 or even 49/50. Well, you get the idea ...
Now turn on the conscience and honestly answer the question - how often do you follow this simple and self-evident principle of management in general in your projects? Do you know why this practice is inherent only to the elect? Yes, because it is a VERY "intelligence-capacious" task - to draw in your head all the details of the future project. Especially if it promises to be huge and with unpredictable turns halfway through. But the project’s fault is not in it. This means only one thing: this management task does not match your (or mine, or his, or her) management skills. This is not about programming as such; not at all that the “Peter” object of the “DotNetDevelopers” class does not know how string x + = string y differs from StringBuilder x.Append (y). The problem is just different - I call it "managerial impotence." And it is much more common (and dangerous) than just impotence! ..
Che is there now in fashion in any weather? Patterns? Honestly, I am not an expert on patterns, but even my acquaintance with them (I read the works of the gang of four and even tasted it!) Is enough to say with almost complete certainty: these patterns of yours do not solve the problem. Maximum - cover up. And as a rule, they simply smear them - evenly over all the surfaces where they passed (more often they crawled) the next zombie from “God Save the Patterns”. To solve this problem at the level of new “stuff” of compilers or frameworks is impossible. Not that level.
When is the revelation about the "perfect code"?
Well, take the pens in your hands and write it down: NO AN EXCELLENT CODE IS EXISTING. But there is a code that solves a specific management problem completely . Therefore, to consider the code separately from the task is the same nonsense how to treat the cell separately from the microscope. Rather, "House-2" will end than this happens! Therefore, if the peculiarity of your task is such that you absolutely do not care if the graphical interface responds or is hopelessly busy with some kind of crazy loop, then your single-threaded code is smart (of course, provided that the loop does not let us down). And if communication with the user is a priority, then you are still another .Net-squalor!
The only thing that makes sense to talk essentially on the topic of a perfect code is the amount of effort that has to be spent on its creation. Here is async / await, shpasiba clever uncles from Microsoft, cool saves time. Therefore (all other things being equal) the code based on async should be recognized objectively better than BeginXXX / EndXXX. But it was understandable even mentally retarded. And not at all to this conclusion, I wanted to bring.
CONCLUSION to which I wanted to bring
The problem of bad projects is not in bad programmers, but in bad managers who ineptly manage the process of creating local code / application as a whole . And this problem should be solved at an appropriate level (which, as you probably did NOT understand, is much, much higher than any compilers there - with all due respect to the latter).
And finally
I have one little idea about solving the problem. It would be nice to sip "weigh", which would be used as a kind of test for the ability to manage this particular project. It would work like this: I click “create a new project”. Next, a tricky algorithm is launched, in the course of which an array of parameters is created, which will describe what in the aforementioned DOTA is called the “Target Vector” and the “Current State Vector”. And then the stage at which you all break off is to indicate the SPECIFIC values of the created parameters for the final state to which I am trying to lead this object / process (this will be my goal). If I am not capable of this (and I am still a wicked one!), Then this means that at the moment I do not have a clear enough picture of what is happening, I can’t set a sufficiently definite goal, and therefore my control (i.e. my code and the project as a whole) will smack yourself guess what. Of course, it is possible to spice up this business with patterns, but then it will turn out like in that joke - “as if someone had shit under the tree”.
But the initialization of the “vector of goals” (in terms of the same DOTA) is not the end of the quest. Further more. Moving from the final state to the initial state, I must divide the management process into a sequence of steps. Each step is a set of states in which the object / process could be at the appropriate stage of its implementation. In fact, we are talking about creating a grid of states (“matrix of possible transitions” (c) DOTA), within which the project will be carried out. Essentially, each state is described by the same set of parameters - only they take on different values. This is where trash managers from God will separate from other husks (regardless of certificates, age, salary, and self-importance). And if someone is capable of vital, convincingly to bring the project from the final state to the initial state - to him and the patterns in hand!
Source: https://habr.com/ru/post/269375/
All Articles