May 6, 2009 at 4:43 What are anti patterns?
Anti-patterns are the exact opposite of patterns. If design patterns
are examples of good programming practices, then there are patterns for solving certain problems. That anti-patterns - their exact opposite, these are patterns of errors that are committed in solving various problems. Part of good programming practices is precisely avoiding anti-patterns. Do not think that this is such an incomprehensible theoretical bullshit - these are specific problems that almost every developer faced. He who is knowledgeable is armed! Consider a few common anti-patterns in programming.
This anti-pattern is probably the oldest in programming. When a programmer is required to write two similar functions, the most “simple” solution is to write one function, copy it, and make some changes to the copy. What problems does this promise? Firstly, portability of the code worsens - if you need similar functionality in another project, you will need to look for all the places where the programmer has saved and transfer them separately. Secondly, the quality of the code decreases - often the programmer forgets to make the required changes to the copied code. Thirdly, code support is becoming more complicated - as if in the original version there was a bug that would need to be fixed in the future, then this bug fell into all that, again, the programmer had accumulated. It also leads to various multiple fixes, which will occur as the bug is located 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 benefits and productivity growth. The main reasons for the occurrence of such errors are the lack of thoughts about the future of development (programmers do not think through their actions), lack of experience (programmers take ready-made examples and modify them, adapting to their needs). The solution is very simple - the creation of common solutions and their use. You should think about this while developing solutions to small problems - it is possible that we will need to solve this problem somewhere else, or solve the same problem, but in a different interpretation. Fourthly, the code review is much more complicated, as the code becomes larger, without visible significant benefits and productivity growth. The main reasons for the occurrence of such errors are the lack of thoughts about the future of development (programmers do not think through their actions), lack of experience (programmers take ready-made examples and modify them, adapting to their needs). The solution is very simple - the creation of common solutions and their use. You should think about this while developing solutions to small problems - it is possible that we will need to solve this problem somewhere else, or solve the same problem, but in a different interpretation. Fourthly, the code review is much more complicated, as the code becomes larger, without visible significant benefits and productivity growth. The main reasons for the occurrence of such errors are the lack of thoughts about the future of 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. You should think about this while developing solutions to small problems - it is possible that we will need to solve this problem somewhere else, or solve the same problem, but in a different interpretation. The main reasons for the occurrence of such errors are the lack of thoughts about the future of 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. You should think about this while developing solutions to small problems - it is possible that we will need to solve this problem somewhere else, or solve the same problem, but in a different interpretation. The main reasons for the occurrence of such errors are the lack of thoughts about the future of 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. You should think about this while developing solutions to small problems - it is possible that we will need to solve this problem somewhere else, or solve the same problem, but in a different interpretation.
Spaghetti code is a poorly structured and poorly designed system, confusing and very difficult to understand. Such code also very often contains many examples of anti-copy-paste programming patterns. Such a code in the future will not be able to parse even its author. In OOP, spaghetti code can be represented as a small number of objects with huge, code-sized methods. The reasons are - development on the principle of “Well, it works! As many as five thousand lines! ”, Ineffective code review, lack of experience in OOP development, remote work of individual programmers. Using spaghetti code repeatedly is impossible and undesirable. 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 the 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 any one design pattern) for all possible and impossible tasks. The problem is that many programmers "use" this anti-pattern without suspecting their own incompetence - they believe that they know the design pattern and use it successfully - everything is fine. The reason among beginners is laziness to learn something new - a beginner tries to solve all problems with the only method that he has mastered. But unfortunately, this is also found among professionals - the programmer really likes to use any pattern and begins to do it everywhere. We must fight this - for each task there is not one, but several, beautiful and optimal solutions - it is precisely to the search for such solutions that effective development comes down to. And only such a development will create an effective system.
A magic number is a constant used in the code for something (most often - data identification), the number itself does not make any sense without an appropriate comment. Numbers have absolutely no semantics. When numbers begin to appear in your project code, the meaning of which is not obvious - this is very bad. A programmer who is not the author of such code will have difficulty explaining how this works. Over time, the author of the code, with the presence of magic numbers, will not be able to explain anything. Numbers make code difficult to understand and refactor. The main reasons for this error are the haste in the development, lack of programming practice. This anti-pattern must be stopped in the bud, stipulating the use of numerical constants before starting development.
Hard coding - the implementation of various environmental data in the implementation. For example, various paths to files, names of processes, devices, and so on. This anti-pattern is closely associated with magic numbers, they are often intertwined. Hardcode - hard-code 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 until moving or renaming files, changing device configurations. On any other system, the code may not work at all right away. As a rule, the programmer almost immediately forgets where and what he hardcoded, even if he does it in order to debug the code. This makes the identification and localization of this anti-pattern very difficult.
Soft coding is a paranoid fear of hard coding. This leads to the fact that absolutely everything is configured and configured, which makes the configuration incredibly complex and opaque. This anti-pattern is the second end of the hard-coding stick and therefore also dangerous. Firstly, when developing a lot of resources, it takes to realize the possibility of settings for absolutely everything. Secondly, the deployment of such a system will also entail additional costs. Before starting to solve a specific problem, you should determine what should be configurable and what is permanent for various systems or can be configured automatically.
In simple words, this is a clever decision. Unnecessary complexity can be introduced into the solution of any problem. This can be like unnecessary checks, parts of the code produced by soft coding, lack of any optimization. This leads to a complication of understanding the code, lowering the speed of work. The reasons are the lack or poor quality of refactoring, the incompetence of the programmer. Fighting is quite simple - thorough code review, effective refactoring should be carried out.
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 an 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", maybe you will have to use them more. Such code only complicates the system, without absolutely any 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, very often better than those invented by the programmer. The developer considers himself the best, therefore, for each task he is trying 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 programmer's work efficiency - since a solution can be found far from optimal or not found at all. It is impossible to completely discard the possibility of an independent solution, since this is a direct road to copy-paste programming. The developer should be guided in the tasks that may appear before him in order to competently 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 creating your own bad decision, if there is a better one. This anti-pattern doubly takes time - because, firstly, time is spent on inventing and implementing one's own solution, and secondly, time is wasted when refactoring such solutions and replacing them with optimal ones. The programmer should be aware of the existence of various solutions for certain circles of tasks, be guided by their advantages and disadvantages.
At any stage of development, you can realize that some part of the code has not changed for a long time and is generally undocumented, or a comment like "// I don’t know how it works, but it works. Do not delete or change!". If nothing is done, then such a code will remain in the project. But refactoring, disassembling it is quite difficult, especially if its author no longer works on the project. It is simpler to foresee the occurrence of such dead code, during development it is necessary to be guided by the fact that the code in the future will probably be slightly optimized or rewritten, but not completely rewritten. The main reasons for the emergence of lava flows are - writing of large parts of the project by one programmer, lack of code review, errors in the design of architecture.
Many novice programmers try 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 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 the options for the development of events and will definitely forget about something. He will spend time selecting the solution that works for him, and later he will spend time reworking this solution. All such selected solutions come out sideways and also good - if in the process of development or debugging. In no case can you get used to this, achieving success on small tasks. If a programmer cannot solve problems in another way - he is incompetent and should not be trusted with development - it will be worse for you.
This anti-pattern is an insufficient check of the correctness of the input data, correction of errors or results of the code. Very often, a programmer thinks that his code will always be in ideal conditions, will never throw errors and will not receive incorrect input data or, what is more, data of the wrong type. But everyone lies ©, so you cannot trust any code, even your own. But this distrust should not be reduced to paranoia, that is, to come to an 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 uninformative comments. The code should not be commented for the sake of commenting! After all, comments are a very useful tool that should help to document the necessary information to facilitate understanding of the code, both for the author in the future and other developers. In no case should you allow developers to have a dialogue in the comments - it is better to transfer this function from comments to specialized tools for code review, or to a personal discussion.
The divine object is an anti-pattern that is quite common among OOP developers. Such an object takes on too many functions and / or stores almost all the data. As a result, we have 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 - incompetence of the developer, one developer taking 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 struggle with such an approach - to divide tasks into subtasks, with the possibility of solving these subtasks by various developers.
Anti-patterns are the main enemies of the developer, and the programmer often gets under their influence due to the pressure of the customer or project manager. The banal lack of time and rush now can easily result in huge problems and inoperability of the system in the future. You should remember a couple of simple principles - "Slow down - you will continue to be" and "Do not brush on - you will not go." Anti-patterns must not only be known, they must know their causes and methods of struggle, and even better, they must be warned in advance against their “use”. A programmer should not write code so that it would then have to be refactored, remember this;)
are examples of good programming practices, then there are patterns for solving certain problems. That anti-patterns - their exact opposite, these are patterns of errors that are committed in solving various problems. Part of good programming practices is precisely avoiding anti-patterns. Do not think that this is such an incomprehensible theoretical bullshit - these are specific problems that almost every developer faced. He who is knowledgeable is armed! Consider a few common anti-patterns 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 most “simple” solution is to write one function, copy it, and make some changes to the copy. What problems does this promise? Firstly, portability of the code worsens - if you need similar functionality in another project, you will need to look for all the places where the programmer has saved and transfer them separately. Secondly, the quality of the code decreases - often the programmer forgets to make the required changes to the copied code. Thirdly, code support is becoming more complicated - as if in the original version there was a bug that would need to be fixed in the future, then this bug fell into all that, again, the programmer had accumulated. It also leads to various multiple fixes, which will occur as the bug is located 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 benefits and productivity growth. The main reasons for the occurrence of such errors are the lack of thoughts about the future of development (programmers do not think through their actions), lack of experience (programmers take ready-made examples and modify them, adapting to their needs). The solution is very simple - the creation of common solutions and their use. You should think about this while developing solutions to small problems - it is possible that we will need to solve this problem somewhere else, or solve the same problem, but in a different interpretation. Fourthly, the code review is much more complicated, as the code becomes larger, without visible significant benefits and productivity growth. The main reasons for the occurrence of such errors are the lack of thoughts about the future of development (programmers do not think through their actions), lack of experience (programmers take ready-made examples and modify them, adapting to their needs). The solution is very simple - the creation of common solutions and their use. You should think about this while developing solutions to small problems - it is possible that we will need to solve this problem somewhere else, or solve the same problem, but in a different interpretation. Fourthly, the code review is much more complicated, as the code becomes larger, without visible significant benefits and productivity growth. The main reasons for the occurrence of such errors are the lack of thoughts about the future of 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. You should think about this while developing solutions to small problems - it is possible that we will need to solve this problem somewhere else, or solve the same problem, but in a different interpretation. The main reasons for the occurrence of such errors are the lack of thoughts about the future of 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. You should think about this while developing solutions to small problems - it is possible that we will need to solve this problem somewhere else, or solve the same problem, but in a different interpretation. The main reasons for the occurrence of such errors are the lack of thoughts about the future of 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. You should think about this while developing solutions to small problems - it is possible that we will need to solve this problem somewhere else, or solve the same problem, but in a different interpretation.
“Come on, you can write not only one function!” Or the Spaghetti code (Spaghetti code)
Spaghetti code is a poorly structured and poorly designed system, confusing and very difficult to understand. Such code also very often contains many examples of anti-copy-paste programming patterns. Such a code in the future will not be able to parse even its author. In OOP, spaghetti code can be represented as a small number of objects with huge, code-sized methods. The reasons are - development on the principle of “Well, it works! As many as five thousand lines! ”, Ineffective code review, lack of experience in OOP development, remote work of individual programmers. Using spaghetti code repeatedly is impossible and undesirable. 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 the 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 any one design pattern) for all possible and impossible tasks. The problem is that many programmers "use" this anti-pattern without suspecting their own incompetence - they believe that they know the design pattern and use it successfully - everything is fine. The reason among beginners is laziness to learn something new - a beginner tries to solve all problems with the only method that he has mastered. But unfortunately, this is also found among professionals - the programmer really likes to use any pattern and begins to do it everywhere. We must fight this - for each task there is not one, but several, beautiful and optimal solutions - it is precisely to the search for such solutions that effective development comes down to. And only such a development will create an effective system.
"What is 42?" Or Magic numbers
A magic number is a constant used in the code for something (most often - data identification), the number itself does not make any sense without an appropriate comment. Numbers have absolutely no semantics. When numbers begin to appear in your project code, the meaning of which is not obvious - this is very bad. A programmer who is not the author of such code will have difficulty explaining how this works. Over time, the author of the code, with the presence of magic numbers, will not be able to explain anything. Numbers make code difficult to understand and refactor. The main reasons for this error are the haste in the development, lack of programming practice. This anti-pattern must 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 implementation of various environmental data in the implementation. For example, various paths to files, names of processes, devices, and so on. This anti-pattern is closely associated with magic numbers, they are often intertwined. Hardcode - hard-code 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 until moving or renaming files, changing device configurations. On any other system, the code may not work at all right away. As a rule, the programmer almost immediately forgets where and what he hardcoded, even if he does it in order to debug the code. This makes the identification and localization of this anti-pattern very difficult.
Soft coding (Soft code)
Soft coding is a paranoid fear of hard coding. This leads to the fact that absolutely everything is configured and configured, which makes the configuration incredibly complex and opaque. This anti-pattern is the second end of the hard-coding stick and therefore also dangerous. Firstly, when developing a lot of resources, it takes to realize the possibility of settings for absolutely everything. Secondly, the deployment of such a system will also entail additional costs. Before starting to solve a specific problem, you should determine what should be configurable and what is permanent for various systems or can be configured automatically.
Accidental complexity
In simple words, this is a clever decision. Unnecessary complexity can be introduced into the solution of any problem. This can be like unnecessary checks, parts of the code produced by soft coding, lack of any optimization. This leads to a complication of understanding the code, lowering the speed of work. The reasons are the lack or poor quality of refactoring, the incompetence of the programmer. Fighting is quite simple - thorough code review, effective refactoring should be carried out.
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 an 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", maybe you will have to use them more. Such code only complicates the system, without absolutely any 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, very often better than those invented by the programmer. The developer considers himself the best, therefore, for each task he is trying 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 programmer's work efficiency - since a solution can be found far from optimal or not found at all. It is impossible to completely discard the possibility of an independent solution, since this is a direct road to copy-paste programming. The developer should be guided in the tasks that may appear before him in order to competently 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 creating your own bad decision, if there is a better one. This anti-pattern doubly takes time - because, firstly, time is spent on inventing and implementing one's own solution, and secondly, time is wasted when refactoring such solutions and replacing them with optimal ones. The programmer should be aware of the existence of various solutions for certain circles of tasks, be guided by their advantages and disadvantages.
“It smells bad from your code” or Lava flow
At any stage of development, you can realize that some part of the code has not changed for a long time and is generally undocumented, or a comment like "// I don’t know how it works, but it works. Do not delete or change!". If nothing is done, then such a code will remain in the project. But refactoring, disassembling it is quite difficult, especially if its author no longer works on the project. It is simpler to foresee the occurrence of such dead code, during development it is necessary to be guided by the fact that the code in the future will probably be slightly optimized or rewritten, but not completely rewritten. The main reasons for the emergence of lava flows are - writing of large parts of the project by one programmer, lack of code review, errors in the design of architecture.
“And if i + 1?” Or Programming by permutation
Many novice programmers try 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 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 the options for the development of events and will definitely forget about something. He will spend time selecting the solution that works for him, and later he will spend time reworking this solution. All such selected solutions come out sideways and also good - if in the process of development or debugging. In no case can you get used to this, achieving success on small tasks. If a programmer cannot solve problems in another way - he is incompetent and should not be trusted with development - it will be worse for you.
“How did you pass a string instead of a number ?!” or Blind faith
This anti-pattern is an insufficient check of the correctness of the input data, correction of errors or results of the code. Very often, a programmer thinks that his code will always be in ideal conditions, will never throw errors and will not receive incorrect input data or, what is more, data of the wrong type. But everyone lies ©, so you cannot trust any code, even your own. But this distrust should not be reduced to paranoia, that is, to come to an 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 uninformative comments. The code should not be commented for the sake of commenting! After all, comments are a very useful tool that should help to document the necessary information to facilitate understanding of the code, both for the author in the future and other developers. In no case should you allow developers to have a dialogue in the comments - it is better to transfer this function from comments to specialized tools for code review, or to a personal discussion.
Divine Object
“I need such and such functionality. - Use MegaCoreObject! “And yet, I need and ...” “I said, use MegaCoreObject!”
The divine object is an anti-pattern that is quite common among OOP developers. Such an object takes on too many functions and / or stores almost all the data. As a result, we have 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 - incompetence of the developer, one developer taking 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 struggle with such an approach - to divide tasks into subtasks, with the possibility of solving these subtasks by various developers.
conclusions
Anti-patterns are the main enemies of the developer, and the programmer often gets under their influence due to the pressure of the customer or project manager. The banal lack of time and rush now can easily result in huge problems and inoperability of the system in the future. You should remember a couple of simple principles - "Slow down - you will continue to be" and "Do not brush on - you will not go." Anti-patterns must not only be known, they must know their causes and methods of struggle, and even better, they must be warned in advance against their “use”. A programmer should not write code so that it would then have to be refactored, remember this;)