The illusion of effective development: design
This post is a continuation of: The illusion of effective development: management
We all studied programming, almost all of us went through the stage of asking questions at forums, in conferences, and sometimes in a team. Conventionally, all respondents can be divided into 2 groups: those who know the answer to your question and those who know how to correctly . They are the prophets of the standard, they are the apostles of the right cause, they and only they can godlessly tighten up your project, hiding behind the perfect architecture and code lining. They are the world backstage of the IT world, which, without knowing it, determines what will be in trend in the next few years.
If you are tired of reading, then just say that the essence of this post is that you think with your head. Or they thought with their own head and kept their thoughts not expressed, if you plan to work on the current place for a long time and productively. Everyone else is welcome under cat.
The problem is as old as the world - using an idea without understanding its meaning. In our case, everything begins when a person who does not have enough experience to understand why they are needed, or who does not have enough knowledge, to formulate the connection between the typical tasks of the industry and the approaches described in the book, meets with advanced design techniques. The result is one - the proposed ideas are taken for granted. And because of the lack of understanding of the scope, these ideas are applied where they are not applicable.
The world of IT is good because those who do not study, he does not stay in it for a long time. And a gradual understanding of why OOP is really needed, patterns, etc. does come to such programmers. Those who did not understand anything, it is very easy to determine by the categoricalness of judgments in favor of an approach and the readiness to recognize as people of the second grade all those who do not adhere to such an approach. And if this is a tmlid at the head of the Hindu regiment, then such behavior can still be somehow explained, but otherwise, I believe that such timblids should learn a lot from the movie hero of the immortal creation of Svetlana Baskova, who calls everyone to be human.
Do not stop asking yourself every time why the approach you are using should be applied in a particular case. Be aware of the problems that this approach solves. Make sure that these problems exist in your project. If, as a result of this simple procedure, you came to the final justification of the form “this is good practice,” or even “my faith is strong”, then perhaps this is an indirect sign that the chosen approach is not appropriate in this case.
')
The mind of every decent young web programmer is agitated by the question: how many connections does highload start with? The mind of every decent architect is occupied by two questions: what is the minimum level of abstraction to do in the designed system so that further expansion does not turn into hell, and also how high a level of abstraction can be done in it so that development and support do not turn into hell. There are a lot of such questions, but it all comes down to exactly which patterns and architecture to use for a project of a certain scale. The problem is complicated by the fact that often ideas about the prospects for development or the attendance of a project are very vague, while solving the problem immediately and fundamentally do not allow time and budget. In this case, the architect is still required to create something that meets all conflicting requirements.
Different people solve this problem in different ways. Someone decides not to bother with the structure, considering that if the project takes off, then there is money to be rewritten from scratch, and if it does not, then there is no need to waste efforts. Someone, designing a system that can do everything, starts to direct the cannon at the sparrow, but by the time of guidance, despite the filigree accuracy of the calculation, it turns out that the sparrow flew away, and the timeframe and budget were exceeded by half. Someone just gets drunk on hopelessness, thus avoiding the solution of the problem. And someone may be lucky enough to guess the requirements for the system, which will put time, and then it turns out a great product with a wonderful architecture. And someone designs according to current requirements or with a small margin at the rate of losing a little time, but at least leaving the possibility of further expansion. As a rule, the first and last approaches are the most viable.
In my opinion, today there are still no clear methods for determining from what point the application of such and such an architectural approach is justified. Those. there are collections of approaches, use cases are described, but the border where such a case begins is not described anywhere. Usually, understanding how to apply what comes with experience, however, to convey a similar experience in words is not an easy task. The specifics of the industry are such that almost every new architecture is different from the existing ones, just so much that the advice on a new architecture to a person who did not deal with the old one was useless.
Just remember that no matter how elegant the pattern in the book may seem, how attractive the idea is to cover all the code with tests, how great it would be to have the architecture “in reserve”, all this may end up being a burden for your project and not help. . Decide for yourself what you need and what you are willing to sacrifice for - far from always neglecting things that a normal code is supposed to be unthinkable without, will throw you into the ninth circle of hell.
Today we have a lot of great projects like github.com, sourceforge.net, etc., not to mention code repositories for specific languages. And it is their presence that has played a significant role in terms of planting the belief that bicycles are bad and that there is always a ready-made solution. Of course, if you decide to write your gui-toolkit for windows or a template engine for php, then I would give up all the unfinished business, get up, button up my pants and go away from your field, expressing the majority opinion.
But as soon as we take on something a little more atypical than the above-mentioned things, the quality problem of those libraries that seem so accessible will arise before us in full growth. By quality, I mean 3 things:
If you look at the quality of libraries soberly, then you can still allow the option when you have to write an analogue yourself. Just because it will be easier. So it will be faster and more efficient. It will be wrong. And your bike really can be special - in the sense that even with the alleged abundance of solutions, none of them will suit you fully. Although you can get indulgence for this blasphemy, putting your version on github. To others burned on it or write your own. And the deployment time of the application is directly proportional to the number of libraries that need to be deployed with it.
Separately, there is the problem of choosing between a new project or the development of an existing solution. Most of this choice of web-programmers - the lion's share of projects on the web is quite typical, for which there are cms engines, web-shops, social networks, etc. At first glance, it always seems that it is logical to finish an existing solution to the requirements of TK, than to write your bike from scratch. This seems especially logical after several projects are carried out on the same engine in a row, and quickly and elegantly. However, you can also burn, resting on the limitations of the architecture or in a fancy layout, or even at the speed with which everything will work after the work is completed. For myself, I derived a rule of thumb - if, according to my estimates, a project takes more than a month, then it is better to write from scratch or on a general-purpose framework. Well, what’s better — I’m better, and you’ll have to draw your own rules depending on what you work with.
Just remember that there are times when parsing xml with regular expressions will be preferable to using binding to libxml, and writing a seemingly simple internet shop will be easier on Yii than on the basis of PrestaShop. Everything, of course, has already been invented before us, but not all of this is embodied in the code in the way that it can be conveniently used.
One of the easiest ways to earn credibility in the IT world is to follow trends. The sooner you join the trend, the better. You will think and check whether the trend is effective in reality - you will not have time in the first rows, and you will not see the honorary title of senior-bleeding-edge-developer. I'm not saying that new is bad, I even believe that the use of new technologies can somehow help you beat the competition (but I still think that a good sales manager or excellent usability will give you an order of magnitude more chances to win the championship than competent architecture). I just want to note that before choosing a new-fangled framework for my project, it’s nice to be sure that:
Again, be aware of the fact that you chose a new technology Y, in the presence of technology X, which is already well tested, has a community and is generally used everywhere.
I thought for a long time what to write here, but somehow it turned out that it was too voluminous or too specific, because of what many would have thought that I was an ideological opponent of some technologies and approaches. Therefore, I will limit myself to five points:
So understand them as you want. And remember about the difference between Olympiad and industrial programming.
Experience is the son of difficult mistakes. And what to do when there is no experience, and you want to avoid mistakes? Here in the course are the books on the pickup. And in the case of programming all sorts of best practices. Having read this and at least having memorized a set of rules for good code, you can write code so that then no one dares to reproach that something is written wrong. It's great. This overlooks the fact that you have to pay for everything. Until you yourself come to the need for techniques (except the simplest ones), they cannot be used effectively and will, for the most part, take your time. If yesterday's student who successfully created dozens of php sites read the “Perfect Code” and tries to use all this in practice, then most likely his work will rise, although the quality of the code will improve in some places. And so it will be as long as he himself does not go through the rake in any large project, until the abstract construction of books does not find a match from real practice. Only then comes the understanding of what, when and why to use.
But one should not go away from the roots - many of the same students, having gained experience over several years, begin to believe that copy-paste and procedural programming belong to the words of the category Those that cannot be called. The reason is the same - fear of being wrong. Unfortunately, now the community is more acceptable to use the right solutions, rather than finding a tool for the task.
Just do not be afraid to make mistakes. If you believe that it will not cost you the loss of reputation and work.
Frankly, this whole article was inspired by the fact that I had to work in teams with different timblids, each of which had their own ideas about how to write the code correctly. They were all in the details right, but the trouble is that these details were very different for each of them. Moreover, I would venture to suggest that if you bring them all at one table in a pub, and then transfer the conversation to the comparison channel of imperative and functional programming or about the differences between Dependency Injection and the good old Factory, it will not do without the intervention of security.
All team leaders are people too, they all have their own beliefs and knowledge gained from the implementation of some of their projects. Sometimes such beliefs correspond to reality, sometimes not. Sometimes the latter may seem to you because you have not yet encountered tasks that would lead you to an understanding of why this should be done. In any case, take everything that the team leader will say as his requirements, and not as really good things. If his advice passes the test of practice - great, but if not, then persuading a person in such errors is usually useless.
There are no universal rules of good form in development. There are rules that can be beneficial in some situation. Even if there are many such situations, it does not mean that you will not encounter another, when the rules that once helped, will be useless. And do not forget to ask yourself the question why you chose this particular solution to the problem, and not another.
We all studied programming, almost all of us went through the stage of asking questions at forums, in conferences, and sometimes in a team. Conventionally, all respondents can be divided into 2 groups: those who know the answer to your question and those who know how to correctly . They are the prophets of the standard, they are the apostles of the right cause, they and only they can godlessly tighten up your project, hiding behind the perfect architecture and code lining. They are the world backstage of the IT world, which, without knowing it, determines what will be in trend in the next few years.
If you are tired of reading, then just say that the essence of this post is that you think with your head. Or they thought with their own head and kept their thoughts not expressed, if you plan to work on the current place for a long time and productively. Everyone else is welcome under cat.
Church of the Perfect Code
The problem is as old as the world - using an idea without understanding its meaning. In our case, everything begins when a person who does not have enough experience to understand why they are needed, or who does not have enough knowledge, to formulate the connection between the typical tasks of the industry and the approaches described in the book, meets with advanced design techniques. The result is one - the proposed ideas are taken for granted. And because of the lack of understanding of the scope, these ideas are applied where they are not applicable.
The world of IT is good because those who do not study, he does not stay in it for a long time. And a gradual understanding of why OOP is really needed, patterns, etc. does come to such programmers. Those who did not understand anything, it is very easy to determine by the categoricalness of judgments in favor of an approach and the readiness to recognize as people of the second grade all those who do not adhere to such an approach. And if this is a tmlid at the head of the Hindu regiment, then such behavior can still be somehow explained, but otherwise, I believe that such timblids should learn a lot from the movie hero of the immortal creation of Svetlana Baskova, who calls everyone to be human.
Do not stop asking yourself every time why the approach you are using should be applied in a particular case. Be aware of the problems that this approach solves. Make sure that these problems exist in your project. If, as a result of this simple procedure, you came to the final justification of the form “this is good practice,” or even “my faith is strong”, then perhaps this is an indirect sign that the chosen approach is not appropriate in this case.
')
From paper airplane to shuttle
The mind of every decent young web programmer is agitated by the question: how many connections does highload start with? The mind of every decent architect is occupied by two questions: what is the minimum level of abstraction to do in the designed system so that further expansion does not turn into hell, and also how high a level of abstraction can be done in it so that development and support do not turn into hell. There are a lot of such questions, but it all comes down to exactly which patterns and architecture to use for a project of a certain scale. The problem is complicated by the fact that often ideas about the prospects for development or the attendance of a project are very vague, while solving the problem immediately and fundamentally do not allow time and budget. In this case, the architect is still required to create something that meets all conflicting requirements.
Different people solve this problem in different ways. Someone decides not to bother with the structure, considering that if the project takes off, then there is money to be rewritten from scratch, and if it does not, then there is no need to waste efforts. Someone, designing a system that can do everything, starts to direct the cannon at the sparrow, but by the time of guidance, despite the filigree accuracy of the calculation, it turns out that the sparrow flew away, and the timeframe and budget were exceeded by half. Someone just gets drunk on hopelessness, thus avoiding the solution of the problem. And someone may be lucky enough to guess the requirements for the system, which will put time, and then it turns out a great product with a wonderful architecture. And someone designs according to current requirements or with a small margin at the rate of losing a little time, but at least leaving the possibility of further expansion. As a rule, the first and last approaches are the most viable.
In my opinion, today there are still no clear methods for determining from what point the application of such and such an architectural approach is justified. Those. there are collections of approaches, use cases are described, but the border where such a case begins is not described anywhere. Usually, understanding how to apply what comes with experience, however, to convey a similar experience in words is not an easy task. The specifics of the industry are such that almost every new architecture is different from the existing ones, just so much that the advice on a new architecture to a person who did not deal with the old one was useless.
Just remember that no matter how elegant the pattern in the book may seem, how attractive the idea is to cover all the code with tests, how great it would be to have the architecture “in reserve”, all this may end up being a burden for your project and not help. . Decide for yourself what you need and what you are willing to sacrifice for - far from always neglecting things that a normal code is supposed to be unthinkable without, will throw you into the ninth circle of hell.
Bike to ride on the walls
Today we have a lot of great projects like github.com, sourceforge.net, etc., not to mention code repositories for specific languages. And it is their presence that has played a significant role in terms of planting the belief that bicycles are bad and that there is always a ready-made solution. Of course, if you decide to write your gui-toolkit for windows or a template engine for php, then I would give up all the unfinished business, get up, button up my pants and go away from your field, expressing the majority opinion.
But as soon as we take on something a little more atypical than the above-mentioned things, the quality problem of those libraries that seem so accessible will arise before us in full growth. By quality, I mean 3 things:
- functionality - you need to personally feel the moment when it turns out that 10% of the functional is missing in the selected library, which will hold 90% of your project. Developers are the same people as you, and usually these very necessary 10% include the dirtiest work for which no one wants to undertake.
- documentation - bad documentation is just the scourge of all young projects, and without it, welcome to the code
- code quality - determines the possibility of expanding and or even studying the API in case of bad and missing documentation
If you look at the quality of libraries soberly, then you can still allow the option when you have to write an analogue yourself. Just because it will be easier. So it will be faster and more efficient. It will be wrong. And your bike really can be special - in the sense that even with the alleged abundance of solutions, none of them will suit you fully. Although you can get indulgence for this blasphemy, putting your version on github. To others burned on it or write your own. And the deployment time of the application is directly proportional to the number of libraries that need to be deployed with it.
Separately, there is the problem of choosing between a new project or the development of an existing solution. Most of this choice of web-programmers - the lion's share of projects on the web is quite typical, for which there are cms engines, web-shops, social networks, etc. At first glance, it always seems that it is logical to finish an existing solution to the requirements of TK, than to write your bike from scratch. This seems especially logical after several projects are carried out on the same engine in a row, and quickly and elegantly. However, you can also burn, resting on the limitations of the architecture or in a fancy layout, or even at the speed with which everything will work after the work is completed. For myself, I derived a rule of thumb - if, according to my estimates, a project takes more than a month, then it is better to write from scratch or on a general-purpose framework. Well, what’s better — I’m better, and you’ll have to draw your own rules depending on what you work with.
Just remember that there are times when parsing xml with regular expressions will be preferable to using binding to libxml, and writing a seemingly simple internet shop will be easier on Yii than on the basis of PrestaShop. Everything, of course, has already been invented before us, but not all of this is embodied in the code in the way that it can be conveniently used.
At the forefront of technology
One of the easiest ways to earn credibility in the IT world is to follow trends. The sooner you join the trend, the better. You will think and check whether the trend is effective in reality - you will not have time in the first rows, and you will not see the honorary title of senior-bleeding-edge-developer. I'm not saying that new is bad, I even believe that the use of new technologies can somehow help you beat the competition (but I still think that a good sales manager or excellent usability will give you an order of magnitude more chances to win the championship than competent architecture). I just want to note that before choosing a new-fangled framework for my project, it’s nice to be sure that:
- at least some of the functionality that is really necessary for your project is present in this framework
- this functionality really can be applied - well, i.e. take and use, I do not dance with a tambourine, so that it somehow earned
- you are so confident in yourself and your subordinates that you know that if you stumble upon a mistake, due to which all development can get up, then you will be able to eliminate it by debugging and digging in the insides of the framework
- you have time to implement the previous item
Again, be aware of the fact that you chose a new technology Y, in the presence of technology X, which is already well tested, has a community and is generally used everywhere.
Theory and practice
I thought for a long time what to write here, but somehow it turned out that it was too voluminous or too specific, because of what many would have thought that I was an ideological opponent of some technologies and approaches. Therefore, I will limit myself to five points:
- Do not take the theoreticians' calculations (this article, for example) or other people's experience if you are not sure that it was obtained on the basis of creating a solution that is very close to yours.
- No matter how persuasive the examples are in the documentation, remember that they are often synthetic
- In general, any concept is invented to solve a problem or a class of similar problems; there is no guarantee that your task fits harmoniously with this class.
- Complicated at first glance, the concept in relation to your task can turn into a display of a couple of lines, understandable to most rural informatics teachers
- Be very careful about the concepts of “not for all” or “ahead of your time”, which for years have remained the lot of a small group of people - they may turn out to be excessively difficult to use, but often simply useless.
So understand them as you want. And remember about the difference between Olympiad and industrial programming.
Just not to be mistaken
Experience is the son of difficult mistakes. And what to do when there is no experience, and you want to avoid mistakes? Here in the course are the books on the pickup. And in the case of programming all sorts of best practices. Having read this and at least having memorized a set of rules for good code, you can write code so that then no one dares to reproach that something is written wrong. It's great. This overlooks the fact that you have to pay for everything. Until you yourself come to the need for techniques (except the simplest ones), they cannot be used effectively and will, for the most part, take your time. If yesterday's student who successfully created dozens of php sites read the “Perfect Code” and tries to use all this in practice, then most likely his work will rise, although the quality of the code will improve in some places. And so it will be as long as he himself does not go through the rake in any large project, until the abstract construction of books does not find a match from real practice. Only then comes the understanding of what, when and why to use.
But one should not go away from the roots - many of the same students, having gained experience over several years, begin to believe that copy-paste and procedural programming belong to the words of the category Those that cannot be called. The reason is the same - fear of being wrong. Unfortunately, now the community is more acceptable to use the right solutions, rather than finding a tool for the task.
Just do not be afraid to make mistakes. If you believe that it will not cost you the loss of reputation and work.
Timlid - our king, father and god
Frankly, this whole article was inspired by the fact that I had to work in teams with different timblids, each of which had their own ideas about how to write the code correctly. They were all in the details right, but the trouble is that these details were very different for each of them. Moreover, I would venture to suggest that if you bring them all at one table in a pub, and then transfer the conversation to the comparison channel of imperative and functional programming or about the differences between Dependency Injection and the good old Factory, it will not do without the intervention of security.
All team leaders are people too, they all have their own beliefs and knowledge gained from the implementation of some of their projects. Sometimes such beliefs correspond to reality, sometimes not. Sometimes the latter may seem to you because you have not yet encountered tasks that would lead you to an understanding of why this should be done. In any case, take everything that the team leader will say as his requirements, and not as really good things. If his advice passes the test of practice - great, but if not, then persuading a person in such errors is usually useless.
Conclusion
There are no universal rules of good form in development. There are rules that can be beneficial in some situation. Even if there are many such situations, it does not mean that you will not encounter another, when the rules that once helped, will be useless. And do not forget to ask yourself the question why you chose this particular solution to the problem, and not another.
Source: https://habr.com/ru/post/151811/
All Articles