Out of scope
My development as a programmer began in 2005 and continues to this day.
Undoubtedly, many readers will be able to boast of more extensive experience, but we
will talk about something else. My professional growth overlapped with an interesting period -
improving the culture of programming in Runet, if I may call it that.
Professionals have always been, but today the knowledge of the average programmer (at
least in the field of best pracices) is incomparably higher than then.
And in itself, this is not bad, fears are caused by the trend itself, which led to a
similar result. With its continuation, we may seriously face the same
the problem with which it all began - namely, with the govnokod, but this time with the
govnokod ennobled, covered by many abstractions, and sometimes it is these
abstractions themselves . Yes, yes, today we again criticize overengineering.
The concept of patterns is not new, the idea of not inventing your bike is sore
, for the lack of tests it is customary to sprinkle ash on your head and repent like in a
final judgment. It is enough to read about 5 books on design to
understand what is now fashionable and how to write code. The catch is different - even after reading
25 books you won’t understand when you need to write which code. To some extent, you can learn
looking at senior comrades who give out ideas of when it is possible to apply
one or another solution, while the train of thought that led to such a decision again
remains behind the scenes.
As a result, the newcomer at best has a certain map in his head describing
when something can be applied, and the map is rather limited. And woe to the newcomer,
if he turns out to be impressionable, and the result is excellent - a person may
have a favorite pattern. And he can carefully carry this pattern through the years, sculpting
it in the most bizarre places, and thereby causing sincere surprise and
genuine hatred of colleagues.
Don't you like TDD? Love to write code in procedural style? Not using EJB?
Ai-ai-ai, how can it be that the earth under your feet is not burning. Any society is divided into
groups, and if you are not ready to join one group, then you will be gladly ranked as
another. As elsewhere, where biological
patterns are at the core of behavior logic , there is competition between groups. Some of the groups
win the honorary prize of the Possession of the Absolute Truth, while the rest are
declared enemies of the human race, at best funny marginals.
Everyone, in general, understands this, just look at any post on the hub
over-engineering - it will be splashed, but in the comments you can see about
ten kilobytes of demagogy on the topic of why the author is still wrong. But nothing
can be done - everyone who wants to go against the established order of things will either be
ignored or ridiculed. The situation is aggravated by the fact that those authorities who
could support the protest with their own names, as a rule, are not interested in this -
they are already sitting in dusty positions, where the rules of the Perfect Code
work, in principle , and they don’t care what’s next In the software engineering segment, people
break spears in disputes on the topic "how to write code correctly."
Until the trend reverses from “write perfect code” to “write code that
solves the current problem,” we are doomed to write test code in interviews with
a pattern that we never even
dreamed of using in a scary dream, and then after devices to work, no less famously stamping tests that
test nothing to achieve the coveted 100% coverage of the code.
The funny thing is that there are people who are ready to sincerely and fervently argue on the topic of
what the actual implementation of the pattern should be under one or another name,
omitting the fact that the name they are arguing about is just a convention for
a person who decided to record his personal experience under that name. The
saddest thing is that there are those who listen to the previous ones and, shaking their heads
sadly, immediately repent that they could not understand the definition correctly, promising to become
better. But healthy self-criticism cannot be replaced with unhealthy self-flagellation, and
they do not get better.
Martin Fowler is our king, father and god. We all honor him as a person who gave a
ruler of hand to countless hordes of novice programmers, and in many respects
determined the worldview of a whole generation of IT specialists. We most likely will never
know how and why it became a measure of code goodness. Perhaps his books became the
very stub for a stream of low-quality programmers who poured into the industry until
the dot-com bubble burst. Or maybe he really was the first to
systematize everything that had been accumulated in terms of program design by that
time. All these are things of bygone days.
And today we have a set of recommendations that have become unspoken rules of good
form in development. Perhaps these rules are good, let's try to outline the boundaries of their
application:
1) Languages with static typing - primarily C ++ and Java.
2) Large software products created on the basis of the interchangeability of the
programmers involved in the project.
3) Software products designed for further development and long-term
maintenance.
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. Problem in
that the rest of the market share is covered in such Talmuds ... nothing. Yes, it is simply
ignored, or rather it would be more accurate to say that the approaches described in the books are
simply not suitable for other products.
Meanwhile, if you look closely, you can notice a huge number of small and
medium-sized projects that do not fit the conditions described above. Here is the
dominance of scripting languages, and teams with a team lead that
you ca n’t just throw out, because the rest of the juniors were typed to the minimum budget, or
even ghostly options that promise to be a good
addition to the scholarship, and slurred forecasts regarding the development project.
A considerable amount of industry software does not change over the years - the programs simply
serve the technical processes for which they were created, and the changes made to them -
purely cosmetic. Of course, the code located there most often leaves much to be
desired, but it is quite expandable within the framework of the requirements that are put to it.
Even more elegant, the uncertainty of future software may appear in the case when
it will develop is determined by how quickly it can enter the market and
recapture investments in order to obtain funds for further development. Abstractions do not
always significantly increase the amount of code, but always increase the time it
takes to write. Surely there are toy (which received huge
funding from the start ) and excessively successful startups who can afford such a
luxury as writing in all respects charitable code. And this is great - there must
be happy programmers somewhere on earth. But such
projects should not be considered as a regularity.
Fault tolerance is rather a matter of preference. We understand that our
programs must work stably. The question is how stable. Everything that
is written by us is written to solve a problem. And if the statement of this problem
does not require 100% fault tolerance, then most likely it really is not
needed. Everything has a price - you have to pay for fault tolerance, spend time
creating wrappers, checks, backup systems. And ultimately our task is not
create a completely indestructible system, and make sure that the cost of improving the
reliability of the system is less than the cost caused by its downtime. It sounds
blasphemous, but when soberly examined, it is so.
Many small projects are interesting in that it is more important for them to be delivered on a
tight schedule than to meet quality requirements. Yes, it is sad, yes it is
wrong, yes it can lead to sad consequences in the future, but such a
model is viable and widespread. Honorable programming masters
rubbing their hands in anticipation of the work of rewriting this shit
normal mind, they refuse to realize that if it weren’t for this
govnokod on which the project was launched, then there would simply be no work for them. They
don’t have an understanding that the money that the customer is ready to pay them now
is the result of a poorly working piece of shit.
By the way, almost
all programmers begin their professional path from this market segment . And tips are pouring on their head, one more remarkable than the other. But the
reality is that following these tips at this stage of its development and
participating 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 either do not
work or are not needed at all because of the high prices. And those who can not yet
effectively perform the role of a “good programmer”, on the contrary, are strongly present
in the labor market in this segment and are actively shy about the failure to fulfill the
covenants of the perfect code.
This is not to say that beginners are advised to use patterns, testing,
extensible architecture by malicious intent, no. All these advisers sincerely wish them
well, without noticing that the tasks they solve are somewhat different.
Applying good practices here will not give positive feedback, they simply don’t
suitable for solving the tasks posed here. Cooking in a cauldron of small and medium
- sized projects and trying to write perfect code, a beginner is doomed to break
deadlines again and again and do what no one needs.
Yes, it’s a sin to hide, your humble servant at one time with honor filled up 2
months-long projects on freelance, exceeding all conceivable deadlines, and was also disgraced
from two works because of low productivity. The reason is simple - I
tried to do everything wisely.
Every novice programmer is faced with the dilemma of two chairs. Education,
according to the laws of the logic of our universe, is possible in two ways - by accepting the
information necessary to achieve the goal, on faith, or by checking all
possible options for achieving the goal with finding the right one. And both options
are not ideal.
Assimilation of the available information is a good way if we know that it is
reliable. And it’s reliable, it’s damn reliable, I’m ready to agree that the
authors of the design books used all the advice given to them in their
projects. I just don’t believe that our programmer will come across a structurally identical
project, and also that a novice programmer will be allowed to work on a structurally
identical project, at least at the level where he will decide which
approaches to apply to him ...
By the way, how to check the accuracy of the information given in such books? Only having
hit the domain of assumptions that the code will change this way or that. Any
sophomore will be able to cite the examples described in books as counter-examples
that will be more concise and effective, while solving the same problem.
Any good practice is almost impossible to falsify, which
It makes you think about accepting it as an infallible truth that answers the question
of 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. The attitude towards such people is,
to put it mildly, negative, and most often - contempt. There are two reasons for the negative:
firstly, a public opinion has been formed that states that a person who does not
use best practices is not a person at all, and secondly, learning from
his own experience will inevitably make mistakes. As a rule, these errors are noticed
his more experienced colleagues, for whom such flaws - are really baby talk.
The trouble is that there is no formalization of the process of teaching programming
, even in the minds of those who have gone through this process. For example, you are an
accomplished programmer, try to
ask the question “why” for each of your actions during the design of the next module or some serious class,
try to justify the sequence of your actions from the point of view of logic, so
that one clearly follows from the other.
To save you time, I’ll say that you won’t succeed. If it works out, then
your stubbornness is worthy of all praise, the same post of reading by you is not worthy,
close it. In the process of creating an architecture, you do not operate with knowledge, but rather
experience. You cannot jump above your head by creating architecture from a book
until you come to the necessity of such constructions yourself. But you can
trick the interviewer into an interview using the opposite statement.
In the magical land of dairy rivers and pink unicorns, dying from kidney
failure due to the absence of other moisture, people are always able to derive
particulars from the general. Unfortunately, they share the same fate as unicorns, so
they do not have time to get to our world with you to bring this
sacred knowledge to it. Therefore, almost all people are not able, on the basis of knowledge
of something general, abstract, to derive particulars, except when it comes to
simple and unambiguous things. Software design is not like that.
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, it's about people
with no experience. If anything, singleton doesn't count. Something in my head does not allow me to take and produce
piece abstractions in the image and likeness of what I read: either a person does not understand
why this is done and as a result, abstraction creates more problems than it solves, or he
honestly admits to himself that he does not see where it can be pushed. Perhaps there are those who are
capable of such a method of training, but I have never met them. And you?
According to my observations, the conclusion 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 breaking on a rake. And who opens the book only to understand
what is commonly called what he learned from his experience. If he didn’t
recognize anything by the time the book was opened, then no approach would work.
Knowledge at the level of a formal description of an object is often not enough for
its successful application. They should be built into logical chains at the level of facts,
which should not only be memorized, but felt. Usually this understanding
comes in the process of practice (less often - when, after a few months or years, you
feel that something in your head has fallen into place and you are ready to use it).
And regardless of whether the programmer read about patterns or not. If the tasks
show the inefficiency of his current approach, he will come to a solution
that will work better. No matter how he calls it in his head. Explaining the
resulting pattern to another programmer is a matter of minutes. And besides, if the
description of the pattern is formed in the brain of each programmer on the examples with
which he dealt, then, even having a common definition, two people, using it,
will talk about quite different things, which again makes reference to the official
patterns junk.
I’ll even take the nerve to say that if programmers are constantly
they use the official names of patterns in their work, and moreover, they are limited
only to these names, without discussing the logic associated with them, it is most likely
either yesterday’s students or avid Java enthusiasts, where using patterns
to circumvent language restrictions is a routine.
All practices aimed at creating extensible code go from the subject
area to the domain of assumptions that this code will be supported and expanded. And
this is the greatest difference between programming and any other engineering
activity - usually, if the unit does not have enough power or functions, then it is
replaced with another unit that is more suitable.
The unspoken principle of programming is that instead of
re- creating it , it’s better to expand or change what you already have. The benefit of technology allows. By the
way, technology allows you to upgrade physical devices to achieve them
necessary functions. Nevertheless, for some reason this is not done. Surely for reasons of a
purely economic nature.
Having two approaches - rewriting from scratch and expanding the finished, we are accustomed to the
fact that the second option is better, less labor intensive. At the same time, forgetting that:
a) in the case of crookedly written non-extensible code, we get a lot of difficulties with the
addition of functionality
b) in the case of creating an extensible code, the rewriting cost is already set
at the initial stage of writing the code
Labor costs will be in both cases, the only question is when they more. And it is precisely
to this question that an experienced programmer should know the answer well. Experienced
an architect can give a task to write a shit, but with one condition - no one
should know about it.
You may not find a place for years due to the fact that you cannot find a place to the
practices you are reading about, but this most likely does not mean that something is
wrong with you . No matter how many patterns you know and use, the only important thing is that you can
apply them to the place. In general, I am convinced that the knowledge of a good designer
can be mastered in a couple of months, but it
takes years to learn how to use them correctly .
If you are not working on a system containing at least dozens of strongly
related classes (and there are a lot of such systems), you don’t have to bother with the
best way to create an orgy from various abstractions so that later it all looks
like light eroticism. You can generally be a good programmer and never get
involved in 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 for
large projects in Java, C #, C ++. In particular, it will be useful to programmers in
scripting languages, because this way you can clearly see the difference in the approach
to programming in, for example, Java and Python. In any case, even if you find an
implementation of a particular pattern, you should not take it to heart,
patterns are usually born or selected within a specific project. So that
chances are that what you saw there cannot be applied to your current
project.
If the authorities require you to write the "correct code" - write! You either really
still don’t understand what is wrong with your professional level, and then it
will be useful for you to do as they say, if your team leader is ideological, don’t argue
with him - the ordinary programmer can’t destroy his faith, and then kicks not getting
you.
Thinking, thinking well before using something that you do not understand. If
it seems unnecessary to you, then it really can be. If you see that
your program needs a side pocket as a dog, don’t write them, you still wo
n’t be able to write them in such a way that they are useful. If you looked at the
list of patterns, and then you were horrified to find that in your code over the past couple of
years, at best, 3-4 of them have been found, but otherwise you are happy with your
code and there is no problem with it, then leave all as it is.
And of course, remember that people's abilities for aggressive rhetoric are always back
proportional to their evidence base. And each time when they will
appeal to a hypothetical situation, the
probability of which is suspiciously small, as an argument for using some approach , just remember the
conditions under which the grandmother can become a grandfather.
Undoubtedly, many readers will be able to boast of more extensive experience, but we
will talk about something else. My professional growth overlapped with an interesting period -
improving the culture of programming in Runet, if I may call it that.
Professionals have always been, but today the knowledge of the average programmer (at
least in the field of best pracices) is incomparably higher than then.
And in itself, this is not bad, fears are caused by the trend itself, which led to a
similar result. With its continuation, we may seriously face the same
the problem with which it all began - namely, with the govnokod, but this time with the
govnokod ennobled, covered by many abstractions, and sometimes it is these
abstractions themselves . Yes, yes, today we again criticize overengineering.
The concept of patterns is not new, the idea of not inventing your bike is sore
, for the lack of tests it is customary to sprinkle ash on your head and repent like in a
final judgment. It is enough to read about 5 books on design to
understand what is now fashionable and how to write code. The catch is different - even after reading
25 books you won’t understand when you need to write which code. To some extent, you can learn
looking at senior comrades who give out ideas of when it is possible to apply
one or another solution, while the train of thought that led to such a decision again
remains behind the scenes.
As a result, the newcomer at best has a certain map in his head describing
when something can be applied, and the map is rather limited. And woe to the newcomer,
if he turns out to be impressionable, and the result is excellent - a person may
have a favorite pattern. And he can carefully carry this pattern through the years, sculpting
it in the most bizarre places, and thereby causing sincere surprise and
genuine hatred of colleagues.
A Short Excursion into Minority Rights
Don't you like TDD? Love to write code in procedural style? Not using EJB?
Ai-ai-ai, how can it be that the earth under your feet is not burning. Any society is divided into
groups, and if you are not ready to join one group, then you will be gladly ranked as
another. As elsewhere, where biological
patterns are at the core of behavior logic , there is competition between groups. Some of the groups
win the honorary prize of the Possession of the Absolute Truth, while the rest are
declared enemies of the human race, at best funny marginals.
Everyone, in general, understands this, just look at any post on the hub
over-engineering - it will be splashed, but in the comments you can see about
ten kilobytes of demagogy on the topic of why the author is still wrong. But nothing
can be done - everyone who wants to go against the established order of things will either be
ignored or ridiculed. The situation is aggravated by the fact that those authorities who
could support the protest with their own names, as a rule, are not interested in this -
they are already sitting in dusty positions, where the rules of the Perfect Code
work, in principle , and they don’t care what’s next In the software engineering segment, people
break spears in disputes on the topic "how to write code correctly."
Until the trend reverses from “write perfect code” to “write code that
solves the current problem,” we are doomed to write test code in interviews with
a pattern that we never even
dreamed of using in a scary dream, and then after devices to work, no less famously stamping tests that
test nothing to achieve the coveted 100% coverage of the code.
The funny thing is that there are people who are ready to sincerely and fervently argue on the topic of
what the actual implementation of the pattern should be under one or another name,
omitting the fact that the name they are arguing about is just a convention for
a person who decided to record his personal experience under that name. The
saddest thing is that there are those who listen to the previous ones and, shaking their heads
sadly, immediately repent that they could not understand the definition correctly, promising to become
better. But healthy self-criticism cannot be replaced with unhealthy self-flagellation, and
they do not get better.
On top of Olympus
Martin Fowler is our king, father and god. We all honor him as a person who gave a
ruler of hand to countless hordes of novice programmers, and in many respects
determined the worldview of a whole generation of IT specialists. We most likely will never
know how and why it became a measure of code goodness. Perhaps his books became the
very stub for a stream of low-quality programmers who poured into the industry until
the dot-com bubble burst. Or maybe he really was the first to
systematize everything that had been accumulated in terms of program design by that
time. All these are things of bygone days.
And today we have a set of recommendations that have become unspoken rules of good
form in development. Perhaps these rules are good, let's try to outline the boundaries of their
application:
1) Languages with static typing - primarily C ++ and Java.
2) Large software products created on the basis of the interchangeability of the
programmers involved in the project.
3) Software products designed for further development and long-term
maintenance.
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. Problem in
that the rest of the market share is covered in such Talmuds ... nothing. Yes, it is simply
ignored, or rather it would be more accurate to say that the approaches described in the books are
simply not suitable for other products.
Black market
Meanwhile, if you look closely, you can notice a huge number of small and
medium-sized projects that do not fit the conditions described above. Here is the
dominance of scripting languages, and teams with a team lead that
you ca n’t just throw out, because the rest of the juniors were typed to the minimum budget, or
even ghostly options that promise to be a good
addition to the scholarship, and slurred forecasts regarding the development project.
A considerable amount of industry software does not change over the years - the programs simply
serve the technical processes for which they were created, and the changes made to them -
purely cosmetic. Of course, the code located there most often leaves much to be
desired, but it is quite expandable within the framework of the requirements that are put to it.
Even more elegant, the uncertainty of future software may appear in the case when
it will develop is determined by how quickly it can enter the market and
recapture investments in order to obtain funds for further development. Abstractions do not
always significantly increase the amount of code, but always increase the time it
takes to write. Surely there are toy (which received huge
funding from the start ) and excessively successful startups who can afford such a
luxury as writing in all respects charitable code. And this is great - there must
be happy programmers somewhere on earth. But such
projects should not be considered as a regularity.
Fault tolerance is rather a matter of preference. We understand that our
programs must work stably. The question is how stable. Everything that
is written by us is written to solve a problem. And if the statement of this problem
does not require 100% fault tolerance, then most likely it really is not
needed. Everything has a price - you have to pay for fault tolerance, spend time
creating wrappers, checks, backup systems. And ultimately our task is not
create a completely indestructible system, and make sure that the cost of improving the
reliability of the system is less than the cost caused by its downtime. It sounds
blasphemous, but when soberly examined, it is so.
Many small projects are interesting in that it is more important for them to be delivered on a
tight schedule than to meet quality requirements. Yes, it is sad, yes it is
wrong, yes it can lead to sad consequences in the future, but such a
model is viable and widespread. Honorable programming masters
rubbing their hands in anticipation of the work of rewriting this shit
normal mind, they refuse to realize that if it weren’t for this
govnokod on which the project was launched, then there would simply be no work for them. They
don’t have an understanding that the money that the customer is ready to pay them now
is the result of a poorly working piece of shit.
By the way, almost
all programmers begin their professional path from this market segment . And tips are pouring on their head, one more remarkable than the other. But the
reality is that following these tips at this stage of its development and
participating 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 either do not
work or are not needed at all because of the high prices. And those who can not yet
effectively perform the role of a “good programmer”, on the contrary, are strongly present
in the labor market in this segment and are actively shy about the failure to fulfill the
covenants of the perfect code.
This is not to say that beginners are advised to use patterns, testing,
extensible architecture by malicious intent, no. All these advisers sincerely wish them
well, without noticing that the tasks they solve are somewhat different.
Applying good practices here will not give positive feedback, they simply don’t
suitable for solving the tasks posed here. Cooking in a cauldron of small and medium
- sized projects and trying to write perfect code, a beginner is doomed to break
deadlines again and again and do what no one needs.
Yes, it’s a sin to hide, your humble servant at one time with honor filled up 2
months-long projects on freelance, exceeding all conceivable deadlines, and was also disgraced
from two works because of low productivity. The reason is simple - I
tried to do everything wisely.
Industry obscurantism
Every novice programmer is faced with the dilemma of two chairs. Education,
according to the laws of the logic of our universe, is possible in two ways - by accepting the
information necessary to achieve the goal, on faith, or by checking all
possible options for achieving the goal with finding the right one. And both options
are not ideal.
Assimilation of the available information is a good way if we know that it is
reliable. And it’s reliable, it’s damn reliable, I’m ready to agree that the
authors of the design books used all the advice given to them in their
projects. I just don’t believe that our programmer will come across a structurally identical
project, and also that a novice programmer will be allowed to work on a structurally
identical project, at least at the level where he will decide which
approaches to apply to him ...
By the way, how to check the accuracy of the information given in such books? Only having
hit the domain of assumptions that the code will change this way or that. Any
sophomore will be able to cite the examples described in books as counter-examples
that will be more concise and effective, while solving the same problem.
Any good practice is almost impossible to falsify, which
It makes you think about accepting it as an infallible truth that answers the question
of 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. The attitude towards such people is,
to put it mildly, negative, and most often - contempt. There are two reasons for the negative:
firstly, a public opinion has been formed that states that a person who does not
use best practices is not a person at all, and secondly, learning from
his own experience will inevitably make mistakes. As a rule, these errors are noticed
his more experienced colleagues, for whom such flaws - are really baby talk.
The trouble is that there is no formalization of the process of teaching programming
, even in the minds of those who have gone through this process. For example, you are an
accomplished programmer, try to
ask the question “why” for each of your actions during the design of the next module or some serious class,
try to justify the sequence of your actions from the point of view of logic, so
that one clearly follows from the other.
To save you time, I’ll say that you won’t succeed. If it works out, then
your stubbornness is worthy of all praise, the same post of reading by you is not worthy,
close it. In the process of creating an architecture, you do not operate with knowledge, but rather
experience. You cannot jump above your head by creating architecture from a book
until you come to the necessity of such constructions yourself. But you can
trick the interviewer into an interview using the opposite statement.
Heuristic impotence
In the magical land of dairy rivers and pink unicorns, dying from kidney
failure due to the absence of other moisture, people are always able to derive
particulars from the general. Unfortunately, they share the same fate as unicorns, so
they do not have time to get to our world with you to bring this
sacred knowledge to it. Therefore, almost all people are not able, on the basis of knowledge
of something general, abstract, to derive particulars, except when it comes to
simple and unambiguous things. Software design is not like that.
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, it's about people
with no experience. If anything, singleton doesn't count. Something in my head does not allow me to take and produce
piece abstractions in the image and likeness of what I read: either a person does not understand
why this is done and as a result, abstraction creates more problems than it solves, or he
honestly admits to himself that he does not see where it can be pushed. Perhaps there are those who are
capable of such a method of training, but I have never met them. And you?
According to my observations, the conclusion 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 breaking on a rake. And who opens the book only to understand
what is commonly called what he learned from his experience. If he didn’t
recognize anything by the time the book was opened, then no approach would work.
Knowledge at the level of a formal description of an object is often not enough for
its successful application. They should be built into logical chains at the level of facts,
which should not only be memorized, but felt. Usually this understanding
comes in the process of practice (less often - when, after a few months or years, you
feel that something in your head has fallen into place and you are ready to use it).
And regardless of whether the programmer read about patterns or not. If the tasks
show the inefficiency of his current approach, he will come to a solution
that will work better. No matter how he calls it in his head. Explaining the
resulting pattern to another programmer is a matter of minutes. And besides, if the
description of the pattern is formed in the brain of each programmer on the examples with
which he dealt, then, even having a common definition, two people, using it,
will talk about quite different things, which again makes reference to the official
patterns junk.
I’ll even take the nerve to say that if programmers are constantly
they use the official names of patterns in their work, and moreover, they are limited
only to these names, without discussing the logic associated with them, it is most likely
either yesterday’s students or avid Java enthusiasts, where using patterns
to circumvent language restrictions is a routine.
Embrace the immense
All practices aimed at creating extensible code go from the subject
area to the domain of assumptions that this code will be supported and expanded. And
this is the greatest difference between programming and any other engineering
activity - usually, if the unit does not have enough power or functions, then it is
replaced with another unit that is more suitable.
The unspoken principle of programming is that instead of
re- creating it , it’s better to expand or change what you already have. The benefit of technology allows. By the
way, technology allows you to upgrade physical devices to achieve them
necessary functions. Nevertheless, for some reason this is not done. Surely for reasons of a
purely economic nature.
Having two approaches - rewriting from scratch and expanding the finished, we are accustomed to the
fact that the second option is better, less labor intensive. At the same time, forgetting that:
a) in the case of crookedly written non-extensible code, we get a lot of difficulties with the
addition of functionality
b) in the case of creating an extensible code, the rewriting cost is already set
at the initial stage of writing the code
Labor costs will be in both cases, the only question is when they more. And it is precisely
to this question that an experienced programmer should know the answer well. Experienced
an architect can give a task to write a shit, but with one condition - no one
should know about it.
Application area
You may not find a place for years due to the fact that you cannot find a place to the
practices you are reading about, but this most likely does not mean that something is
wrong with you . No matter how many patterns you know and use, the only important thing is that you can
apply them to the place. In general, I am convinced that the knowledge of a good designer
can be mastered in a couple of months, but it
takes years to learn how to use them correctly .
If you are not working on a system containing at least dozens of strongly
related classes (and there are a lot of such systems), you don’t have to bother with the
best way to create an orgy from various abstractions so that later it all looks
like light eroticism. You can generally be a good programmer and never get
involved in 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 for
large projects in Java, C #, C ++. In particular, it will be useful to programmers in
scripting languages, because this way you can clearly see the difference in the approach
to programming in, for example, Java and Python. In any case, even if you find an
implementation of a particular pattern, you should not take it to heart,
patterns are usually born or selected within a specific project. So that
chances are that what you saw there cannot be applied to your current
project.
If the authorities require you to write the "correct code" - write! You either really
still don’t understand what is wrong with your professional level, and then it
will be useful for you to do as they say, if your team leader is ideological, don’t argue
with him - the ordinary programmer can’t destroy his faith, and then kicks not getting
you.
What to do?
Thinking, thinking well before using something that you do not understand. If
it seems unnecessary to you, then it really can be. If you see that
your program needs a side pocket as a dog, don’t write them, you still wo
n’t be able to write them in such a way that they are useful. If you looked at the
list of patterns, and then you were horrified to find that in your code over the past couple of
years, at best, 3-4 of them have been found, but otherwise you are happy with your
code and there is no problem with it, then leave all as it is.
And of course, remember that people's abilities for aggressive rhetoric are always back
proportional to their evidence base. And each time when they will
appeal to a hypothetical situation, the
probability of which is suspiciously small, as an argument for using some approach , just remember the
conditions under which the grandmother can become a grandfather.