What are anti-patterns?
Anti-patterns are the exact opposite of patterns. If design patterns are
These are examples of good programming practices, that is, patterns for solving certain problems. That anti-patterns are their exact opposite, these are patterns of errors that are made when solving various problems. Part of the practice of good programming is precisely the avoidance of anti-patterns. Do not think that this is such an incomprehensible theoretical garbage - these are specific problems that almost every developer has encountered. Who knows, he is armed! Let us consider several anti-patterns that have been implemented in programming.
This anti-pattern is probably the oldest in programming. When a programmer is required to write two similar functions, the simplest solution is to write one function, copy it, and make some changes to the copy. What problems does it promise? First, the portability of the code deteriorates - if you need such functionality in another project, you will need to look for all the places where the programmer accumulated and transferred them separately. Secondly, the quality of the code decreases - often the programmer forgets to make the required changes to the copied code. Thirdly, the support of the code becomes more complicated - as if in the initial version there was a bug, which in the future will need to be fixed, then this bug got into all that, again, the programmer accumulated. This also leads to the emergence of various multiple fixes that will occur as the bug is found in different parts of the code, for one single bug. Fourthly, the code review is much more complicated as the code becomes larger, without visible significant gains and productivity gains. The main reasons for the occurrence of such errors are the lack of thoughts about future development (programmers do not think through their actions), lack of experience (programmers take ready-made examples and modify, adapting to their needs). The solution is very simple - the creation of common solutions and their use. This should be thought of even when developing solutions to small problems — it is possible that we will need to solve this problem somewhere else, or solve this same problem, but in a different interpretation.
Spaghetti code is a poorly structured and poorly designed system, tangled and very difficult to understand. Such code also very often contains many examples of anti-pattern copy-paste programming. Such code in the future will not be able to parse even its author. In OOP, a spaghetti code can be represented as a small number of objects with huge methods of code size. The reasons are - the development of the principle "Oh well, it also works! As many as five thousand lines! ”, Ineffective code review, lack of experience in OOP development, remote work of individual programmers. It is impossible and undesirable to reuse spaghetti code. If a spaghetti code begins to appear in your project, and you just need to expand the functionality that it implements - do not be lazy, refactor spaghetti completely or write this part again! Having lost a little time now - you will get a huge plus in the future. Or vice versa - you lose if you leave the spaghetti code in the project.
')
Golden Hammer - confidence in the complete universality of any solution. In practice, this is the application of one solution (most often of any one design pattern) for all possible and impossible tasks. The problem is that many programmers “use” this anti-pattern unaware of their own incompetence — they believe that they know the design pattern and successfully use it — all is well. The reason for the newcomers is laziness to learn something new - the newcomer is trying to solve all the problems with the only method he has mastered. But unfortunately, it is also found among professionals - the programmer loves to use any pattern and starts doing it everywhere. It is necessary to fight this - for each task there is not one, but several, beautiful and optimal solutions - it is to the search for such solutions that effective development comes down. And only such development will allow creating an effective system.
The magic number is a constant used in the code for something (most often data identification), the number itself does not make any sense without a corresponding comment. Numbers carry absolutely no semantics. When numbers appear in the code of your project, the meaning of which is not obvious - this is very bad. A programmer who is not the author of such a code will be able to explain how it works with difficulty. Over time, the author of the code, with the presence of magic numbers, will not be able to explain anything. Numbers make it difficult to understand the code and refactor it. The main reasons for this error - the rush in the development, the lack of programming practice. This anti-pattern should be stopped in the bud, stipulating the use of numerical constants before starting development.
Hard coding - the introduction of various data about the environment in the implementation. For example - various file paths, names of processes, devices, and so on. This anti-pattern is closely related to magic numbers, often they are intertwined. Zahardkodit - hard write the value of any data in the code. The main danger posed by this anti-pattern is intolerance. In the developer's system, the code will work properly before moving or renaming files, changing device configurations. On any other system, the code may not work at all immediately. As a rule, the programmer almost immediately forgets where and what he says, even if he does so in order to debug the code. This makes the identification and localization of this anti-pattern very difficult. We need to fight this by specifying a ban on hard coding before starting development and conducting a thorough code review.
Soft coding - paranoid fear of hard coding. This leads to the fact that absolutely everything that makes the configuration incredibly complex and opaque is opaque and customizable. This anti-pattern is the second end of a hard-coding stick and is therefore also dangerous. Firstly, when developing, a lot of resources are spent on implementing the possibility of customization of absolutely everything. Secondly, the deployment of such a system would also entail additional costs. Before you begin solving a particular task, you should determine what should be settable and what is constant for different systems or can be configured automatically.
In simple words - this is the cleverness of the solution. Unnecessary complexity can be introduced into the solution of any task. These can be like unnecessary checks, parts of the code produced by soft coding, the absence of any optimization. This leads to the complication of understanding the code, lowering the speed of work. The reasons are the absence or poor quality of refactoring, the incompetence of the programmer. The fight is quite simple - you should conduct thorough code review, effective refactoring.
This anti-pattern means saving unused parts of the system that remain after optimization or refactoring. Often, after refactoring when, which is the result of the anti-pattern, some parts of the code remain in the system, although they are no longer used. Also, some parts of the code can be left “for the future”, perhaps they will have to use them. This code only complicates the system, without carrying absolutely no practical value. An effective method of dealing with boat anchors is code refactoring to eliminate them, as well as the development planning process, in order to prevent the occurrence of anchors.
The meaning of this anti-pattern is that the programmer develops his own solution for a problem for which there are already solutions that are often better than those thought up by the programmer. The developer considers himself the best, so for each task he tries to come up with his own solution, despite the experience of his predecessors. Most often, this only leads to a loss of time and a decrease in the efficiency of the programmer’s work, since the solution can be found far from being optimal or not found at all. It is impossible to completely discard the possibility of an independent decision, since this is a direct way to lead to copy-paste programming. The developer must be guided in the tasks that may appear before him to correctly solve them - using ready-made solutions or inventing their own. Very often the cause of this anti-pattern is a banal lack of time. And time is money.
This anti-pattern is very closely connected with the simple invention of the bicycle - it is the creation of its own bad solution, with the existence of the best. This anti-pattern is doubly time consuming - because, firstly, time is spent on the invention and implementation of its own solution, secondly, time is spent when refactoring such solutions and replacing them with optimal ones. The programmer must be aware of the existence of various solutions for certain groups of tasks, and be guided in their advantages and disadvantages.
At some stage of development, you may realize that some part of the code has not changed for a very long time and is generally undocumented, or such code is accompanied by a comment like "// I don’t know how it works, but it works. Do not delete or change!". If nothing is done, then such code will remain in the project. But to refactor, to disassemble it is quite difficult, especially if its author is no longer working on a project. It is easier to foresee the emergence of such a dead code, while developing you should be guided by the fact that the code in the future may be slightly optimized or added, but not rewritten in any way. The main causes of lava flows are the writing of large parts of the project by one programmer, the lack of code review, errors in the design of the architecture.
Many novice programmers are trying to solve some problems by brute force - not brute force solutions, namely the selection of parameters, the order of calling functions, and so on. All these games with +1, -1 to parameters and similar things eliminate only the symptoms, and do not give an understanding of what is happening. And if the programmer does not understand what is happening, then he will not be able to foresee all variants of the development of events and will forget about something. He will spend time selecting the solution that works for him and later will spend time reworking this decision. All such selected solutions climbs sideways and more well - if in the process of development or debugging. By no means one can get used to this, achieving success on small tasks. If a programmer cannot solve problems in another way - he is incompetent and he should not trust the development - you will be worse off.
This anti-pattern is insufficient validation of the input data, correction of an error or the results of the code operation. Very often, a programmer thinks that his code will always be in ideal conditions, will never give an error and will not receive incorrect input data or, what's more, data of the wrong type. But everyone lies ©, so you can not trust any code, even your own. But one should not bring this distrust to paranoia, that is, to come to the anti-pattern of unnecessary complexity. You just need to remember about checking the input data and possible problems with someone else's code that you use.
The result of the “work” of this anti-pattern is a large number of unnecessary and non-informative comments. Code should not be commented for comment! After all, comments are a very useful tool that should help document the necessary information to facilitate understanding of the code, both to the author in the future and to other developers. In no case should we allow a dialogue of developers in the comments - it is better to transfer this function from comments to specialized tools for code review, or to personal discussion.
A divine object is an anti-pattern that is quite often found in OOP developers. Such an object takes on too many functions and / or stores almost all data in it. As a result, we have an intolerable code, which, moreover, is difficult to understand. Also, such code is quite difficult to maintain, given that the entire system depends almost exclusively on it. The reasons are the incompetence of the developer, the taking by one developer of a large part of the work (especially when the size of the work "exceeds" the level of experience of this developer). It is necessary to fight this approach - to break tasks into subtasks, with the possibility of solving these subtasks by various developers.
Anti-patterns are the main enemies of a developer; a programmer often falls under their influence because of the pressure of a customer or a project manager. The banal lack of time and haste now can easily lead to huge problems and system malfunction in the future. It should be remembered a couple of simple principles - "Hush you go - you will continue" and "Do not help - you will not go." Anti-patterns should not just be known, they should be aware of their causes and methods of struggle, and even better - to warn themselves in advance against their “use”. The programmer should not write the code so that it then had to be refactored, remember this;)
These are examples of good programming practices, that is, patterns for solving certain problems. That anti-patterns are their exact opposite, these are patterns of errors that are made when solving various problems. Part of the practice of good programming is precisely the avoidance of anti-patterns. Do not think that this is such an incomprehensible theoretical garbage - these are specific problems that almost every developer has encountered. Who knows, he is armed! Let us consider several anti-patterns that have been implemented in programming.
Copy and Paste Programming
This anti-pattern is probably the oldest in programming. When a programmer is required to write two similar functions, the simplest solution is to write one function, copy it, and make some changes to the copy. What problems does it promise? First, the portability of the code deteriorates - if you need such functionality in another project, you will need to look for all the places where the programmer accumulated and transferred them separately. Secondly, the quality of the code decreases - often the programmer forgets to make the required changes to the copied code. Thirdly, the support of the code becomes more complicated - as if in the initial version there was a bug, which in the future will need to be fixed, then this bug got into all that, again, the programmer accumulated. This also leads to the emergence of various multiple fixes that will occur as the bug is found in different parts of the code, for one single bug. Fourthly, the code review is much more complicated as the code becomes larger, without visible significant gains and productivity gains. The main reasons for the occurrence of such errors are the lack of thoughts about future development (programmers do not think through their actions), lack of experience (programmers take ready-made examples and modify, adapting to their needs). The solution is very simple - the creation of common solutions and their use. This should be thought of even when developing solutions to small problems — it is possible that we will need to solve this problem somewhere else, or solve this same problem, but in a different interpretation.
“Come on, you can write not only one function!” Or Spaghetti code (Spaghetti code)
Spaghetti code is a poorly structured and poorly designed system, tangled and very difficult to understand. Such code also very often contains many examples of anti-pattern copy-paste programming. Such code in the future will not be able to parse even its author. In OOP, a spaghetti code can be represented as a small number of objects with huge methods of code size. The reasons are - the development of the principle "Oh well, it also works! As many as five thousand lines! ”, Ineffective code review, lack of experience in OOP development, remote work of individual programmers. It is impossible and undesirable to reuse spaghetti code. If a spaghetti code begins to appear in your project, and you just need to expand the functionality that it implements - do not be lazy, refactor spaghetti completely or write this part again! Having lost a little time now - you will get a huge plus in the future. Or vice versa - you lose if you leave the spaghetti code in the project.
')
Golden hammer
Golden Hammer - confidence in the complete universality of any solution. In practice, this is the application of one solution (most often of any one design pattern) for all possible and impossible tasks. The problem is that many programmers “use” this anti-pattern unaware of their own incompetence — they believe that they know the design pattern and successfully use it — all is well. The reason for the newcomers is laziness to learn something new - the newcomer is trying to solve all the problems with the only method he has mastered. But unfortunately, it is also found among professionals - the programmer loves to use any pattern and starts doing it everywhere. It is necessary to fight this - for each task there is not one, but several, beautiful and optimal solutions - it is to the search for such solutions that effective development comes down. And only such development will allow creating an effective system.
"What for 42?" Or Magic numbers (Magic numbers)
The magic number is a constant used in the code for something (most often data identification), the number itself does not make any sense without a corresponding comment. Numbers carry absolutely no semantics. When numbers appear in the code of your project, the meaning of which is not obvious - this is very bad. A programmer who is not the author of such a code will be able to explain how it works with difficulty. Over time, the author of the code, with the presence of magic numbers, will not be able to explain anything. Numbers make it difficult to understand the code and refactor it. The main reasons for this error - the rush in the development, the lack of programming practice. This anti-pattern should be stopped in the bud, stipulating the use of numerical constants before starting development.
“What does d: \ proj \ tests.dat mean?” Or Hard code
Hard coding - the introduction of various data about the environment in the implementation. For example - various file paths, names of processes, devices, and so on. This anti-pattern is closely related to magic numbers, often they are intertwined. Zahardkodit - hard write the value of any data in the code. The main danger posed by this anti-pattern is intolerance. In the developer's system, the code will work properly before moving or renaming files, changing device configurations. On any other system, the code may not work at all immediately. As a rule, the programmer almost immediately forgets where and what he says, even if he does so in order to debug the code. This makes the identification and localization of this anti-pattern very difficult. We need to fight this by specifying a ban on hard coding before starting development and conducting a thorough code review.
Soft coding
Soft coding - paranoid fear of hard coding. This leads to the fact that absolutely everything that makes the configuration incredibly complex and opaque is opaque and customizable. This anti-pattern is the second end of a hard-coding stick and is therefore also dangerous. Firstly, when developing, a lot of resources are spent on implementing the possibility of customization of absolutely everything. Secondly, the deployment of such a system would also entail additional costs. Before you begin solving a particular task, you should determine what should be settable and what is constant for different systems or can be configured automatically.
Unnecessary complexity (Accidental complexity)
In simple words - this is the cleverness of the solution. Unnecessary complexity can be introduced into the solution of any task. These can be like unnecessary checks, parts of the code produced by soft coding, the absence of any optimization. This leads to the complication of understanding the code, lowering the speed of work. The reasons are the absence or poor quality of refactoring, the incompetence of the programmer. The fight is quite simple - you should conduct thorough code review, effective refactoring.
Boat anchor
This anti-pattern means saving unused parts of the system that remain after optimization or refactoring. Often, after refactoring when, which is the result of the anti-pattern, some parts of the code remain in the system, although they are no longer used. Also, some parts of the code can be left “for the future”, perhaps they will have to use them. This code only complicates the system, without carrying absolutely no practical value. An effective method of dealing with boat anchors is code refactoring to eliminate them, as well as the development planning process, in order to prevent the occurrence of anchors.
The invention of the bicycle (Reinventing the wheel)
The meaning of this anti-pattern is that the programmer develops his own solution for a problem for which there are already solutions that are often better than those thought up by the programmer. The developer considers himself the best, so for each task he tries to come up with his own solution, despite the experience of his predecessors. Most often, this only leads to a loss of time and a decrease in the efficiency of the programmer’s work, since the solution can be found far from being optimal or not found at all. It is impossible to completely discard the possibility of an independent decision, since this is a direct way to lead to copy-paste programming. The developer must be guided in the tasks that may appear before him to correctly solve them - using ready-made solutions or inventing their own. Very often the cause of this anti-pattern is a banal lack of time. And time is money.
The invention of the unicycle (Reinventing the square wheel)
This anti-pattern is very closely connected with the simple invention of the bicycle - it is the creation of its own bad solution, with the existence of the best. This anti-pattern is doubly time consuming - because, firstly, time is spent on the invention and implementation of its own solution, secondly, time is spent when refactoring such solutions and replacing them with optimal ones. The programmer must be aware of the existence of various solutions for certain groups of tasks, and be guided in their advantages and disadvantages.
“Your code smells bad” or Lava flow
At some stage of development, you may realize that some part of the code has not changed for a very long time and is generally undocumented, or such code is accompanied by a comment like "// I don’t know how it works, but it works. Do not delete or change!". If nothing is done, then such code will remain in the project. But to refactor, to disassemble it is quite difficult, especially if its author is no longer working on a project. It is easier to foresee the emergence of such a dead code, while developing you should be guided by the fact that the code in the future may be slightly optimized or added, but not rewritten in any way. The main causes of lava flows are the writing of large parts of the project by one programmer, the lack of code review, errors in the design of the architecture.
“And if i + 1?” Or brute-force programming (Programming by permutation)
Many novice programmers are trying to solve some problems by brute force - not brute force solutions, namely the selection of parameters, the order of calling functions, and so on. All these games with +1, -1 to parameters and similar things eliminate only the symptoms, and do not give an understanding of what is happening. And if the programmer does not understand what is happening, then he will not be able to foresee all variants of the development of events and will forget about something. He will spend time selecting the solution that works for him and later will spend time reworking this decision. All such selected solutions climbs sideways and more well - if in the process of development or debugging. By no means one can get used to this, achieving success on small tasks. If a programmer cannot solve problems in another way - he is incompetent and he should not trust the development - you will be worse off.
“How did you pass a string instead of a number ?!” or Blind faith
This anti-pattern is insufficient validation of the input data, correction of an error or the results of the code operation. Very often, a programmer thinks that his code will always be in ideal conditions, will never give an error and will not receive incorrect input data or, what's more, data of the wrong type. But everyone lies ©, so you can not trust any code, even your own. But one should not bring this distrust to paranoia, that is, to come to the anti-pattern of unnecessary complexity. You just need to remember about checking the input data and possible problems with someone else's code that you use.
Thoughtless commenting
The result of the “work” of this anti-pattern is a large number of unnecessary and non-informative comments. Code should not be commented for comment! After all, comments are a very useful tool that should help document the necessary information to facilitate understanding of the code, both to the author in the future and to other developers. In no case should we allow a dialogue of developers in the comments - it is better to transfer this function from comments to specialized tools for code review, or to personal discussion.
Divine Object (God Object)
“I need this kind of functionality. - Use MegaCoreObject! “And I also need it and ...” “I told you, use MegaCoreObject!”
A divine object is an anti-pattern that is quite often found in OOP developers. Such an object takes on too many functions and / or stores almost all data in it. As a result, we have an intolerable code, which, moreover, is difficult to understand. Also, such code is quite difficult to maintain, given that the entire system depends almost exclusively on it. The reasons are the incompetence of the developer, the taking by one developer of a large part of the work (especially when the size of the work "exceeds" the level of experience of this developer). It is necessary to fight this approach - to break tasks into subtasks, with the possibility of solving these subtasks by various developers.
findings
Anti-patterns are the main enemies of a developer; a programmer often falls under their influence because of the pressure of a customer or a project manager. The banal lack of time and haste now can easily lead to huge problems and system malfunction in the future. It should be remembered a couple of simple principles - "Hush you go - you will continue" and "Do not help - you will not go." Anti-patterns should not just be known, they should be aware of their causes and methods of struggle, and even better - to warn themselves in advance against their “use”. The programmer should not write the code so that it then had to be refactored, remember this;)
Source: https://habr.com/ru/post/59005/
All Articles