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.

    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

    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

    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

        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

    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.

    Also popular now: