The process of creating an architecture of a website or an application, or even establishing an effective workflow, involves facing with recurring difficulties. Naturally, developers do not have to look for a solution to a particular problem every time it arises since most of the well-known solutions can be reused and adjusted for a whole bunch of problems. Generally, design patterns are multi-functional solutions that can be applied to a wide range of scenarios. These patterns help solve the problems that commonly occur and optimize the code. And while design patterns are created to improve the process of development by utilizing specially allotted formulas, in some cases, everything goes wrong despite all the efforts of developers. Then they are called anti-patterns.
For the first time, this term was mentioned in the book of the same name released in 1998. It refers to common solutions that were initially designed to be useful; however, in fact, they do more harm than good.
These patterns can turn out to be harmful for several reasons. For instance, if the developer applies the pattern in the wrong context or time (patterns that were effective previously, may not work today), or the whole paradigm is not efficient at all. Also, anti-patterns are called patterns of failure. However, any developer can recognize and stay away from these patterns of failure. In this article, we present an overview of ten common web development anti-patterns that can mislead you that you have a well-optimized code.
1. Hardcoding
This is the most famous anti-pattern that appears in the first few chapters in the appropriate books. Hardcoding refers to the practices of storing input information, for instance, host name or the file path, in the source code, instead of storing such information in the configuration file or a database or another external source.
The major problem of the hard code is that it only operates in a definite environment, and if the conditions change, the source code has to be modified and, in most cases, many times in a row.
2. Softcoding
When the developers try to stay away from hard-coding, they can find another pitfall – the anti-pattern that we call “softcoding” – which is the opposite to the previously stated one.
This computer coding term refers to storing information in external resources instead of source code, for instance, the business logic finds its storage in databases. Developers often dread that the rules of business are liable to be modified and that they will have to rewrite the code.
On the other hand, the soft code can make the program a bit too abstract to understand, debug, and maintain it.
3. Reinventing the Wheel
This idiomatic metaphor refers to the development anti-pattern that calls for duplicating a basic method that has already been optimized or created by other developers. In other words, it usually takes place when the development team wants to make a fresh start and write the whole functionality from scratch, without taking the existing methods or libraries into consideration.
Reinventing the wheel refers not only to time-wasting procedures but also the solutions, particularly for fundamental functionality, that are hardly ever as good as classic ones that have already been implemented by a lot of developers and tested by many users.
4. Dependency Hell
This is another common anti-pattern that is basically referred to the opposite of the previously stated anti-pattern. If a developer applies too many third-party solutions, APIs, or libraries without thinking of their necessity instead of writing the code independently, it is easy to find yourself in a situation when there are too many elements that are hard to manage. In other words, these abundant dependencies are incompatible with each other in the majority of cases.
This anti-pattern can be avoided by using a smart, thought-out development strategy. Even the tiniest architecture details should be considered and discussed. In addition, it is a good idea to use packaging managers that allow for quick updating of interdependent dependencies.
5. Spaghetti Code
Probably the most well-known development anti-pattern is the “spaghetti code”. It implies the web application that is difficult to maintain, modify, or debug through the absence of accurate architecture.
The inspiration for this idiomatic metaphor comes from a bowl of spaghetti that, like the bunch of bad code, is complicated and tangled. This code is considered to be extremely messed up, and it is impossible to figure out how it exactly works since the readability is awfully low.
Spaghetti code is usually the consequence of the blend of dreadful development practices, for instance, an abundance of exceptions, go-to statements, and threads, the absence of proper conditional blocks, the presence of elements and parts that have minimal or no relationships between each other, or is not well-documented, etc.
6. Premature Optimization
Good timing defines every detail in code optimization. Premature optimization refers to the situation when a developer decided to focus on small performance victories and optimize code too early in the development process before figuring out all the details.
Donald Knuth once made an exhaustive note that premature optimization is the root of all evil. This might be a hyperbole; however, it stresses the bunch of possible problems that premature optimization can cause. For instance, if the developer optimizes for the performance beforehand while the architecture is not ready, he or she might reduce the readability of the code by adding redundant elements, making the maintenance and debugging procedures difficult to perform.
To put an end to premature optimization, you should follow the YAGNI principle. The abbreviation stands for the “You Ain’t Gonna Need It” principle that is based on the doctrine when the developer refuses to add particular elements when there is no immediate need for it. In other words, you should apply some functionality only when you actually need it, instead of when you think you need it.
7. Copy-and-paste Programming
This coding principle refers to the situation when a developer creates something that contradicts the “Don’t Repeat Yourself” coding principle, and instead of establishing a common solution, he imbeds already-existing code snippets to various places and then edits them to make it suitable for a certain context.
It can result in the appearance of code that is extremely repetitious since the code parts a developer inserted have only minor differences.
Copy-and-paste type of programming is a common practice not only for beginners but also experienced developers. However, to achieve the best results, programmers should apply their personal pre-written and well-tested code snippets for a specific problem that can prevent them from unpredictable recurrences.
8. Programming by Permutation
Programming by permutation that is sometimes called “programming by accident” or “by-try programming” is an anti-pattern in software development that refers to a situation when the problem is solved by making small modifications and testing them one by one. If they behave the way it satisfies the developer, this modification will be implemented.
This approach can simply initiate the presence of new bugs in the code that would not necessarily be recognized at once. Moreover, it is sometimes impossible to recognize whatever a particular solution is a perfect option for every scenario or not.
9. Cargo Cult Programming
This odd name comes from a well-known aboriginal phenomenon named “cargo cult.” These were cults that originated in the South Pacific region after the second World War due to the fact that contact with a civilized nation made the Aborigines think that manufactured products brought on merchant or cargo ships were created by supernatural powers. They believed that magical rites performed by high shamans will bring the cargo ships again.
When it comes to computer programming, cargo cult anti-pattern introduces the application of code parts, libraries, frameworks, design patterns, and another program structures that work for others, but in your particular situation have no purpose. For the most part, developers do not even understand how they work or why do they even apply them. This is a bad practice for two reasons. First, because they make the app too redundant, second because new bugs can be easily introduced to the code.
10. Lava Flow
This anti-pattern was named after the lava flow that comes from the crater of a volcano. First, lava moves too quickly to stop and later, after solidification it becomes hard to extract.
In a programming jargon, the term “lava flow” refers to the situation that a developer has to deal with a low-quality code that contains redundant or/and inferior parts that appear to be integrated into the app; however, it remains unclear how it affects the program or if it does affect it at all. This brings with it a great risk of removing such parts.
It is a usual situation when it comes to the inherited or legacy code, the code that as been written by another developer carelessly and without complying with the documentation, and then forwarded to another developer. Another common situation is when the development stage has occurred too briefly.
Lava flows can be discarded by comprehensive testing and refactoring, but that is only in theory. The practice shows that the realization of such actions is quite hard or impossible. The most workable scenario is to set up a thought-out architecture and well-designed workflow.
