Out of scope
My development as a programmer began in 2005 and continues to this day.
Undoubtedly, many readers will be able to boast a more extensive experience, but the speech
will talk about something else. My professional growth superimposed on an interesting period -
Improving the culture of programming in runet, if you can call it that.
Professionals have always been, but today the average programmer
in any case in the field of best pracices) is incomparably higher than it was then.
And this in itself is not bad, concerns are caused by the trend itself which led to
similar result. With its continuation, we can seriously face the same
the problem that started it all - namely with the govnokod, but this time
shitty-sanctioned, covered by a variety of abstractions, and sometimes by these
abstractions and being. Yes, yes, today we again criticize overinering.
The concept of patterns is not new, the idea of ​​not inventing your bike is filled
it is accepted to sprinkle ashes on the head and repent as if
doom trial. It’s enough to read about 5 design books to
understand what is now fashionable and how to write code. The catch is in another - even after reading
25 books you do not understand when you need to write some code. To some extent you can learn
looking at older comrades who give ideas on when to apply
this or that decision, while the train of thought that led to such a decision again
remains behind the scenes.
')
As a result, a beginner, at best, has a certain card in his head that describes
when you can use anything, and the map is rather limited. And woe to the newcomer,
if it turns out to be impressionable, and the result will be excellent - a person can
appear favorite pattern. And he can carefully carry this pattern over the years, sculpt
him in the most bizarre places, and thus causing sincere surprise and
genuine hatred of colleagues.
You do not like TDD? Do you like to write procedural code? Not using EJB?
Ai-ai-ai, how about you only the earth under your feet does not burn. Any society is divided into
groups, and if you are not ready to join one group, then you will be happily counted as
other. As elsewhere, where biological logic underlies the logic of behavior
patterns, there is competition between groups. Some of the groups
wins the honorary prize of the Law of Possession of the Absolute Truth, the rest
declared enemies of the human race, in the best case funny fringe.
All, in general, understand this, just look at any post on Habré, dedicated
overinering - it will be missed, but in the comments you can see it with
ten kilobytes of demagogy on why all the same author is wrong. But do nothing
it is impossible - everyone who wants to go against the existing order of things will either
ignored or ridiculed. The situation is aggravated by the fact that those authorities
could have supported the protest with their name, as a rule, they are not interested in this -
they are already sitting in dust-free positions, where the rules of the Perfect Code are in principle
work, and they no longer care that in the next segment of soft-building people
break spears in disputes on the topic "how to correctly write code."
Until the trend reversal from “write perfect code” to “write code,
solving the current problem ", we are doomed to write famously at the interviews test code with
the implementation of the pattern that it did not occur to us to use even in the
a terrible dream, and then, after finding a job, it is no less famously to stamp tests,
testing nothing to achieve the coveted 100% code coverage.
The funny thing is that there are people who are ready to argue sincerely and ardently on the topic
what kind of implementation of a pattern under one name or another should be,
omitting the fact that the name they argue about is merely a convention for
a person who has decided to record his personal experience under this name. The most
sad that there are those who listen to the previous ones and, sadly shaking their heads,
they replied that they could not understand the definition correctly, promising to become
it is better. But healthy self-criticism cannot be replaced by unhealthy self-flagellation, and
they don't get any better.
Martin Fowler is our king, father and god. We all honor him as a person
ruler on the hands of countless hordes of novice programmers, and in many ways
determined the worldview of a whole generation of IT shnik. We probably never
We will learn how and why it became a measure of code goodness. Perhaps his books have become that
the very stub for the flow of substandard programmers who have poured into the industry before
moment until the dotcom bubble burst. Or maybe he is really the first to
systematized everything that was accumulated in terms of designing programs to that
of time. All this is a matter of days gone by.
And today we have a set of recommendations that have become the unspoken rules of good
tones in development. Perhaps these rules are good, let's try to delineate their boundaries.
application:
1) Languages ​​with static typing - primarily C ++ and Java.
2) Large software products created on the basis of interchangeability
programmers involved in the project.
3) Software products designed for further development and long-term
escort.
4) software designed for fairly stringent reliability requirements - corporate
solutions in general.
It seems to be normal conditions, covering a considerable share of the software market. The problem is in
that the rest of the market is covered in such talmudas ... no way. Yes she is just
ignored, or rather it would be more correct to say that the approaches described in the books
just not suitable for other products.
Meanwhile, if you look closely, you can see a huge number of small and
medium projects that do not fit the conditions described above. Here and
dominance of scripting languages, and teams with timlid, which is not so easy
you will throw out, because the rest of the juniors were recruited in favor of the minimum budget, and
now and then working for the idea and ghostly options that promise to be good
addition to scholarships, and vague projections regarding the development of the project.
A considerable amount of industry-specific software does not change over the years - programs are simply
serve technical processes for which they were created, and changes made to them -
purely cosmetic. Of course, the code located there often leaves much to be desired.
better, but it is quite expandable within the framework of the requirements that are put to it.
Even more graceful, the uncertainty of the future software can come forward when
whether it will develop is determined by how quickly it can enter the market and
discourage investment to obtain funds for further development. Abstraction not
always significantly increase the amount of code, but always increase its time
writing. Surely there is a toy (received from the start a huge
funding) and excessively successful startups who can afford such
luxury as writing in all parameters charitable code. And it's great - should
there are happy programmers somewhere on earth. But should not be considered such
projects as a pattern.
Fault tolerance is more a matter of preference. We understand that our
programs should work stably. The question is how stable. Everything, that
written by us, written to solve some problem. And if in the formulation of this problem
it is not required to provide 100% fault tolerance, then most likely it’s really not
need Everything has a price - you have to pay for fault tolerance, spend time on
creation of wrappers, checks, backup systems. And ultimately our task is not
create a completely unkillable system, and make the cost of raising
reliability of the system turned out to be less than the costs caused by its downtime Sounds
blasphemous, but when soberly considered the way it is.
Many small projects are interesting because it is more important for them to be handed over to
deadlines than meet the requirements of quality. Yes it's sad yes it is
wrong, yes it can lead to sad consequences in the future, but such
the model is viable and common. Honorable Programming Masters,
rubbing hands in anticipation of the work of rewriting this govnokoda to
normal mind, refuse to be aware that if it were not for this
if the project was able to run, then there would be no work for them. Have
they do not understand that the money that the customer is willing to pay them now,
appeared as a result of a poorly working piece of govnokod.
By the way, it is from this market segment that they begin their professional career almost
all programmers. And they have tips on their head, one more wonderful than the other. But
the reality is that following these tips at this stage of their development and when
Participation in such projects is a direct road to failure. The paradox of the situation is that
those who can really follow good practices in this market segment or not
work, or do not need at all because of high prices. And those who can not yet
effectively play the role of a "good programmer", on the contrary, they are in every possible way present
in the labor market in this segment and are actively shypnayutsya for non-compliance
covenants of perfect code.
This is not to say that beginners are advised to use patterns, testing,
extensible by malice, no. All these advisers sincerely wish them
well, without noticing that the tasks they solve are somewhat different.
The application of good practices here will not give positive feedback, they simply do not
suitable for solving the tasks set here. Cooking in a pot of small and medium
projects and trying to write perfect code, the beginner is doomed again and again to break
deadlines and do what no one needs.
Yes, what a sin to confess, your humble servant in due time flunked with honor 2
multi-month project on freelance, exceeding all imaginable terms, as well as in disgrace
was thrown out with two jobs due to low productivity. The reason is simple - I
tried to do everything according to the mind.
Every novice programmer is faced with the dilemma of two chairs. Training,
according to the laws of logic of our universe, perhaps in two ways - by accepting
information necessary to achieve the goal, on faith, or by checking all
possible options to achieve the goal of finding the right one. And both options
turn out not to be perfect.
Learning the information available is a good way if we know that it is
authentic. And she’s credible, she’s damn sure, I’m ready to agree that
the authors of the design books used all the advice given to them in their
projects. I just do not believe that our programmer will fall structurally identical
project, and also that a novice programmer will be allowed to work on structurally
an identical project, at least at the level where it will decide which
approaches to use it ...
By the way, how to check the accuracy of the information given in such books? Only
hitting the realm of assumptions that the code will change this way or that way. Any
a sophomore will be able to give counter-examples to the examples described in the books,
which will be laconic and efficient, while solving the same problem.
It’s almost impossible to falsify any good practice.
makes you think of accepting it as an infallible truth that answers the question
about how to write programs. These practices in certain cases increase
the likelihood that in the event of a possible code extension you will avoid some
problems. No more.
The second option is an independent search for a solution. Attitudes toward such people
to put it mildly negative, and more often - contempt. The negative goes for two reasons:
Firstly, a public opinion has been formed, stating that a person is not
using best practices is not a person at all, and secondly, studying at
your experience will inevitably make mistakes. As a rule, these errors notice
his more experienced colleagues, for whom such flaws - and really baby talk.
The trouble is that the formalization of the process of learning programming
absent, even in the heads of those who have gone through this process. For example you
held programmer, try while designing the next module or
how many serious classes to ask the question "why" for each of its actions,
try from the point of view of logic to justify the sequence of your actions, so
so that one thing clearly follows from the other.
To save your time, I will say that you will not succeed. If it works, then
your stubbornness is worthy of all praise, this post you read is not worthy,
close it. In the process of creating an architecture, you do not operate with knowledge, but rather
by experience. You can’t jump above your head creating a book-based architecture until
until you come to the need for such constructions yourself. But you can
cheat the interviewer on the interview, using the opposite statement.
In the magical land of milk rivers and pink unicorns dying from renal
failure due to the absence of other moisture, people are always able to remove from
general private Unfortunately, they suffer the same fate as unicorns, therefore
to get to our world with you they do not have time to bring it into it
sacred knowledge. Therefore, almost all people are not capable on the basis of knowledge
something common, abstract, to bring private, except when it comes to
simple and unambiguous things. Software design is not.
I searched in vain and for a long time for people who would be able to read a gang of four, and
then build abstractions and successfully apply them in your code. If anything, talking about people
without experience. If anything, singleton does not count. Something in my head does not allow to take and produce
piece abstractions in the image and likeness of the read: either the person does not understand
why it is done and as a result abstraction creates more problems than it solves, or it
honestly admits to himself that he does not see where this can be stuck. Perhaps there are those who
I am capable of such a way of learning, but I have never met them. And you?
According to my observations, the withdrawal of the general from the particular is a much more feasible task,
that everyone copes with. Yes, I'm talking about the case when a person himself comes to
Patterns beating on a rake. And that opens the book just to understand
as is commonly called what he learned from experience. If he so nothing
I found out by the time the book was opened, then no approach would work anymore.
Knowledge at the level of a formal description of the subject is often insufficient for successful
its application. They must be embedded in logical chains at the fact level,
which should not just be learned, but felt. Usually such an understanding
comes in the process of practice (less often - when, in a few months or years you
feel that something in my head fell into place and you are ready to use it).
And regardless of whether the programmer read about the patterns or not. If tasks
will show the ineffectiveness of his current approach, then he will come to a decision
which will work better. It doesn't matter how he calls it in his head. To explain
the resulting pattern to another programmer is a minute thing. And besides, if
description of the pattern is formed in the brain of each programmer on those examples with
whom he dealt with, then, even having a general definition, two people using him,
They will talk about quite different things, which again makes it binding to the official
junk patterns.
I even take the liberty to say that if programmers are constantly
they use in their work the official names of patterns, and moreover are limited
Only these names, without discussing the logic associated with them, then most likely it’s
either yesterday's students, or avid Java lovers, where the use of patterns
to circumvent the limitations of the language is the essence of routine.
All practices aimed at creating extensible code go away from the subject
areas in the range of assumptions that this code will be maintained and expanded. AND
this is the greatest difference between programming and any other engineering
activities - usually, if the unit does not have enough power or functions, then
replace with another unit, more suitable.
The unspoken programming principle states that instead of creating
again, it is better to expand or change the existing one. The benefit of technology allows. TO
technology allows the word and upgrade physical devices to achieve them
necessary functions. However, for some reason this is not being done. For certain reasons
purely economic nature.
Having two approaches - rewriting from scratch and expanding the finished one, we are used to
the fact that the second option is better is less labor intensive. While forgetting that:
a) in the case of crookedly written non-extensible code, we get great difficulties with
adding functionality
b) in the case of creating an expandable code, the cost of rewriting is laid down already
at the stage of the initial writing of the code
Labor costs will be in both cases, the only question is when they are more. And precisely
An experienced programmer should know the answer to this question. Experienced
An architect can give a task to write a shit, but with one condition - no one
should know about it.
You can not find a place for years due to the fact that you can not find a place
practices that you read about, but this most likely does not mean that something is not with you
So. No matter how many patterns you know and use, it’s just that you can
apply them to the place. I am generally convinced that the amount of knowledge of a good designer
can be mastered in a couple of months, but to learn how to apply them correctly
it will take years.
In case you are not working on a system containing at least dozens of strongly
related classes (and there are a lot of such systems), you do not need to bother your head
better to make an orgy of various abstractions so that then it all looks
like light erotica. You generally can be a good programmer and never
plunge into such a project, traveling between small projects and systems with
low connectivity.
If you still want to understand who uses it and why, then study the code
large projects in Java, C #, C ++. In particular, it will be useful to programmers on
scripting languages, because so you can clearly see the difference in approach
To programming on, for example, Java and Python. In any case, even if you find
the implementation of a particular pattern should not be taken to heart,
patterns are usually born or selected within a specific project. So that
chances are high that what you see there cannot be applied in your current
project.
If the authorities require you to write the "correct code" - write! Are you either true
do not yet understand what is wrong with your professional level, and then it is useful for you
will do as they say, but if your timlid is an ideological person, do not argue
with him, to an ordinary programmer, his faith cannot be destroyed, and then he will not be kicked
you.
To think, to think well before you use something that you do not understand. If a
it seems unnecessary to you, it may indeed be so. If you see that
tests are necessary for your program as a dog's side pocket - do not write them, you don't care
you can’t write them to benefit. If you are familiar with
the list of patterns, and then with horror found that in your code for the last couple
At best, 3-4 years have found shelter at best, but otherwise you are satisfied with your
code, and with its maintenance there are no problems, then leave everything as it is.
And, of course, remember that people's ability to aggressive rhetoric is always back
proportional to their evidence base. And every time you will be in quality
argument to use some approach to appeal to a hypothetical situation,
the probability of occurrence of which is suspiciously small, just remember when
conditions grandmother can become a grandfather.
Undoubtedly, many readers will be able to boast a more extensive experience, but the speech
will talk about something else. My professional growth superimposed on an interesting period -
Improving the culture of programming in runet, if you can call it that.
Professionals have always been, but today the average programmer
in any case in the field of best pracices) is incomparably higher than it was then.
And this in itself is not bad, concerns are caused by the trend itself which led to
similar result. With its continuation, we can seriously face the same
the problem that started it all - namely with the govnokod, but this time
shitty-sanctioned, covered by a variety of abstractions, and sometimes by these
abstractions and being. Yes, yes, today we again criticize overinering.
The concept of patterns is not new, the idea of ​​not inventing your bike is filled
it is accepted to sprinkle ashes on the head and repent as if
doom trial. It’s enough to read about 5 design books to
understand what is now fashionable and how to write code. The catch is in another - even after reading
25 books you do not understand when you need to write some code. To some extent you can learn
looking at older comrades who give ideas on when to apply
this or that decision, while the train of thought that led to such a decision again
remains behind the scenes.
')
As a result, a beginner, at best, has a certain card in his head that describes
when you can use anything, and the map is rather limited. And woe to the newcomer,
if it turns out to be impressionable, and the result will be excellent - a person can
appear favorite pattern. And he can carefully carry this pattern over the years, sculpt
him in the most bizarre places, and thus causing sincere surprise and
genuine hatred of colleagues.
A brief excursion into minority rights
You do not like TDD? Do you like to write procedural code? Not using EJB?
Ai-ai-ai, how about you only the earth under your feet does not burn. Any society is divided into
groups, and if you are not ready to join one group, then you will be happily counted as
other. As elsewhere, where biological logic underlies the logic of behavior
patterns, there is competition between groups. Some of the groups
wins the honorary prize of the Law of Possession of the Absolute Truth, the rest
declared enemies of the human race, in the best case funny fringe.
All, in general, understand this, just look at any post on Habré, dedicated
overinering - it will be missed, but in the comments you can see it with
ten kilobytes of demagogy on why all the same author is wrong. But do nothing
it is impossible - everyone who wants to go against the existing order of things will either
ignored or ridiculed. The situation is aggravated by the fact that those authorities
could have supported the protest with their name, as a rule, they are not interested in this -
they are already sitting in dust-free positions, where the rules of the Perfect Code are in principle
work, and they no longer care that in the next segment of soft-building people
break spears in disputes on the topic "how to correctly write code."
Until the trend reversal from “write perfect code” to “write code,
solving the current problem ", we are doomed to write famously at the interviews test code with
the implementation of the pattern that it did not occur to us to use even in the
a terrible dream, and then, after finding a job, it is no less famously to stamp tests,
testing nothing to achieve the coveted 100% code coverage.
The funny thing is that there are people who are ready to argue sincerely and ardently on the topic
what kind of implementation of a pattern under one name or another should be,
omitting the fact that the name they argue about is merely a convention for
a person who has decided to record his personal experience under this name. The most
sad that there are those who listen to the previous ones and, sadly shaking their heads,
they replied that they could not understand the definition correctly, promising to become
it is better. But healthy self-criticism cannot be replaced by unhealthy self-flagellation, and
they don't get any better.
On top of Olympus
Martin Fowler is our king, father and god. We all honor him as a person
ruler on the hands of countless hordes of novice programmers, and in many ways
determined the worldview of a whole generation of IT shnik. We probably never
We will learn how and why it became a measure of code goodness. Perhaps his books have become that
the very stub for the flow of substandard programmers who have poured into the industry before
moment until the dotcom bubble burst. Or maybe he is really the first to
systematized everything that was accumulated in terms of designing programs to that
of time. All this is a matter of days gone by.
And today we have a set of recommendations that have become the unspoken rules of good
tones in development. Perhaps these rules are good, let's try to delineate their boundaries.
application:
1) Languages ​​with static typing - primarily C ++ and Java.
2) Large software products created on the basis of interchangeability
programmers involved in the project.
3) Software products designed for further development and long-term
escort.
4) software designed for fairly stringent reliability requirements - corporate
solutions in general.
It seems to be normal conditions, covering a considerable share of the software market. The problem is in
that the rest of the market is covered in such talmudas ... no way. Yes she is just
ignored, or rather it would be more correct to say that the approaches described in the books
just not suitable for other products.
Black market
Meanwhile, if you look closely, you can see a huge number of small and
medium projects that do not fit the conditions described above. Here and
dominance of scripting languages, and teams with timlid, which is not so easy
you will throw out, because the rest of the juniors were recruited in favor of the minimum budget, and
now and then working for the idea and ghostly options that promise to be good
addition to scholarships, and vague projections regarding the development of the project.
A considerable amount of industry-specific software does not change over the years - programs are simply
serve technical processes for which they were created, and changes made to them -
purely cosmetic. Of course, the code located there often leaves much to be desired.
better, but it is quite expandable within the framework of the requirements that are put to it.
Even more graceful, the uncertainty of the future software can come forward when
whether it will develop is determined by how quickly it can enter the market and
discourage investment to obtain funds for further development. Abstraction not
always significantly increase the amount of code, but always increase its time
writing. Surely there is a toy (received from the start a huge
funding) and excessively successful startups who can afford such
luxury as writing in all parameters charitable code. And it's great - should
there are happy programmers somewhere on earth. But should not be considered such
projects as a pattern.
Fault tolerance is more a matter of preference. We understand that our
programs should work stably. The question is how stable. Everything, that
written by us, written to solve some problem. And if in the formulation of this problem
it is not required to provide 100% fault tolerance, then most likely it’s really not
need Everything has a price - you have to pay for fault tolerance, spend time on
creation of wrappers, checks, backup systems. And ultimately our task is not
create a completely unkillable system, and make the cost of raising
reliability of the system turned out to be less than the costs caused by its downtime Sounds
blasphemous, but when soberly considered the way it is.
Many small projects are interesting because it is more important for them to be handed over to
deadlines than meet the requirements of quality. Yes it's sad yes it is
wrong, yes it can lead to sad consequences in the future, but such
the model is viable and common. Honorable Programming Masters,
rubbing hands in anticipation of the work of rewriting this govnokoda to
normal mind, refuse to be aware that if it were not for this
if the project was able to run, then there would be no work for them. Have
they do not understand that the money that the customer is willing to pay them now,
appeared as a result of a poorly working piece of govnokod.
By the way, it is from this market segment that they begin their professional career almost
all programmers. And they have tips on their head, one more wonderful than the other. But
the reality is that following these tips at this stage of their development and when
Participation in such projects is a direct road to failure. The paradox of the situation is that
those who can really follow good practices in this market segment or not
work, or do not need at all because of high prices. And those who can not yet
effectively play the role of a "good programmer", on the contrary, they are in every possible way present
in the labor market in this segment and are actively shypnayutsya for non-compliance
covenants of perfect code.
This is not to say that beginners are advised to use patterns, testing,
extensible by malice, no. All these advisers sincerely wish them
well, without noticing that the tasks they solve are somewhat different.
The application of good practices here will not give positive feedback, they simply do not
suitable for solving the tasks set here. Cooking in a pot of small and medium
projects and trying to write perfect code, the beginner is doomed again and again to break
deadlines and do what no one needs.
Yes, what a sin to confess, your humble servant in due time flunked with honor 2
multi-month project on freelance, exceeding all imaginable terms, as well as in disgrace
was thrown out with two jobs due to low productivity. The reason is simple - I
tried to do everything according to the mind.
Industry-scale obscurantism
Every novice programmer is faced with the dilemma of two chairs. Training,
according to the laws of logic of our universe, perhaps in two ways - by accepting
information necessary to achieve the goal, on faith, or by checking all
possible options to achieve the goal of finding the right one. And both options
turn out not to be perfect.
Learning the information available is a good way if we know that it is
authentic. And she’s credible, she’s damn sure, I’m ready to agree that
the authors of the design books used all the advice given to them in their
projects. I just do not believe that our programmer will fall structurally identical
project, and also that a novice programmer will be allowed to work on structurally
an identical project, at least at the level where it will decide which
approaches to use it ...
By the way, how to check the accuracy of the information given in such books? Only
hitting the realm of assumptions that the code will change this way or that way. Any
a sophomore will be able to give counter-examples to the examples described in the books,
which will be laconic and efficient, while solving the same problem.
It’s almost impossible to falsify any good practice.
makes you think of accepting it as an infallible truth that answers the question
about how to write programs. These practices in certain cases increase
the likelihood that in the event of a possible code extension you will avoid some
problems. No more.
The second option is an independent search for a solution. Attitudes toward such people
to put it mildly negative, and more often - contempt. The negative goes for two reasons:
Firstly, a public opinion has been formed, stating that a person is not
using best practices is not a person at all, and secondly, studying at
your experience will inevitably make mistakes. As a rule, these errors notice
his more experienced colleagues, for whom such flaws - and really baby talk.
The trouble is that the formalization of the process of learning programming
absent, even in the heads of those who have gone through this process. For example you
held programmer, try while designing the next module or
how many serious classes to ask the question "why" for each of its actions,
try from the point of view of logic to justify the sequence of your actions, so
so that one thing clearly follows from the other.
To save your time, I will say that you will not succeed. If it works, then
your stubbornness is worthy of all praise, this post you read is not worthy,
close it. In the process of creating an architecture, you do not operate with knowledge, but rather
by experience. You can’t jump above your head creating a book-based architecture until
until you come to the need for such constructions yourself. But you can
cheat the interviewer on the interview, using the opposite statement.
Heuristic powerlessness
In the magical land of milk rivers and pink unicorns dying from renal
failure due to the absence of other moisture, people are always able to remove from
general private Unfortunately, they suffer the same fate as unicorns, therefore
to get to our world with you they do not have time to bring it into it
sacred knowledge. Therefore, almost all people are not capable on the basis of knowledge
something common, abstract, to bring private, except when it comes to
simple and unambiguous things. Software design is not.
I searched in vain and for a long time for people who would be able to read a gang of four, and
then build abstractions and successfully apply them in your code. If anything, talking about people
without experience. If anything, singleton does not count. Something in my head does not allow to take and produce
piece abstractions in the image and likeness of the read: either the person does not understand
why it is done and as a result abstraction creates more problems than it solves, or it
honestly admits to himself that he does not see where this can be stuck. Perhaps there are those who
I am capable of such a way of learning, but I have never met them. And you?
According to my observations, the withdrawal of the general from the particular is a much more feasible task,
that everyone copes with. Yes, I'm talking about the case when a person himself comes to
Patterns beating on a rake. And that opens the book just to understand
as is commonly called what he learned from experience. If he so nothing
I found out by the time the book was opened, then no approach would work anymore.
Knowledge at the level of a formal description of the subject is often insufficient for successful
its application. They must be embedded in logical chains at the fact level,
which should not just be learned, but felt. Usually such an understanding
comes in the process of practice (less often - when, in a few months or years you
feel that something in my head fell into place and you are ready to use it).
And regardless of whether the programmer read about the patterns or not. If tasks
will show the ineffectiveness of his current approach, then he will come to a decision
which will work better. It doesn't matter how he calls it in his head. To explain
the resulting pattern to another programmer is a minute thing. And besides, if
description of the pattern is formed in the brain of each programmer on those examples with
whom he dealt with, then, even having a general definition, two people using him,
They will talk about quite different things, which again makes it binding to the official
junk patterns.
I even take the liberty to say that if programmers are constantly
they use in their work the official names of patterns, and moreover are limited
Only these names, without discussing the logic associated with them, then most likely it’s
either yesterday's students, or avid Java lovers, where the use of patterns
to circumvent the limitations of the language is the essence of routine.
Embrace the immensity
All practices aimed at creating extensible code go away from the subject
areas in the range of assumptions that this code will be maintained and expanded. AND
this is the greatest difference between programming and any other engineering
activities - usually, if the unit does not have enough power or functions, then
replace with another unit, more suitable.
The unspoken programming principle states that instead of creating
again, it is better to expand or change the existing one. The benefit of technology allows. TO
technology allows the word and upgrade physical devices to achieve them
necessary functions. However, for some reason this is not being done. For certain reasons
purely economic nature.
Having two approaches - rewriting from scratch and expanding the finished one, we are used to
the fact that the second option is better is less labor intensive. While forgetting that:
a) in the case of crookedly written non-extensible code, we get great difficulties with
adding functionality
b) in the case of creating an expandable code, the cost of rewriting is laid down already
at the stage of the initial writing of the code
Labor costs will be in both cases, the only question is when they are more. And precisely
An experienced programmer should know the answer to this question. Experienced
An architect can give a task to write a shit, but with one condition - no one
should know about it.
Application area
You can not find a place for years due to the fact that you can not find a place
practices that you read about, but this most likely does not mean that something is not with you
So. No matter how many patterns you know and use, it’s just that you can
apply them to the place. I am generally convinced that the amount of knowledge of a good designer
can be mastered in a couple of months, but to learn how to apply them correctly
it will take years.
In case you are not working on a system containing at least dozens of strongly
related classes (and there are a lot of such systems), you do not need to bother your head
better to make an orgy of various abstractions so that then it all looks
like light erotica. You generally can be a good programmer and never
plunge into such a project, traveling between small projects and systems with
low connectivity.
If you still want to understand who uses it and why, then study the code
large projects in Java, C #, C ++. In particular, it will be useful to programmers on
scripting languages, because so you can clearly see the difference in approach
To programming on, for example, Java and Python. In any case, even if you find
the implementation of a particular pattern should not be taken to heart,
patterns are usually born or selected within a specific project. So that
chances are high that what you see there cannot be applied in your current
project.
If the authorities require you to write the "correct code" - write! Are you either true
do not yet understand what is wrong with your professional level, and then it is useful for you
will do as they say, but if your timlid is an ideological person, do not argue
with him, to an ordinary programmer, his faith cannot be destroyed, and then he will not be kicked
you.
What to do?
To think, to think well before you use something that you do not understand. If a
it seems unnecessary to you, it may indeed be so. If you see that
tests are necessary for your program as a dog's side pocket - do not write them, you don't care
you can’t write them to benefit. If you are familiar with
the list of patterns, and then with horror found that in your code for the last couple
At best, 3-4 years have found shelter at best, but otherwise you are satisfied with your
code, and with its maintenance there are no problems, then leave everything as it is.
And, of course, remember that people's ability to aggressive rhetoric is always back
proportional to their evidence base. And every time you will be in quality
argument to use some approach to appeal to a hypothetical situation,
the probability of occurrence of which is suspiciously small, just remember when
conditions grandmother can become a grandfather.
Source: https://habr.com/ru/post/178035/
All Articles