Introduction
Hope you guys are doing well. Let's start... Today we are going to learn about what is Anti-Pattern and how we can avoid this and where it impacts our business.
What is Anti-Pattern?
An anti-pattern is one that is called or considered a bad system design, which eventually adds "technical debt" to the project and leads to pressure on CAPEX. Because bad design pattern leads huge amount of maintenance and is hard to extend if you need them in future. In this article, we are going to look into a few anti-patterns which should avoid in our project(s).
1. God Object
The God Object is one that does a lot of use cases, such as adding users, doing transactions, and third-party API calls. This object has accessed across your application since it does a lot of work, which eventually bit hard to extend in future. For our extension, we add on extra, instead of reducing weightage in this object. To refactor this, first understand what this God Object does, and how many modules it has, and segregate this as a single responsible pattern. So the class will behave as you want. For eg., if you going to use a user object, it will only contain user method(s) and be able to get only user data instead of some other works.
2. Singleton
This is a familiar pattern that everyone knows about it and they are used to it in their project, however, this is one anti-pattern, because it hides some information that violates the Object Oriented Principle.
3. Spaghetti
Most common anti-pattern due to non-structure methodology. For eg., Random files are available in random folders, which is eventually hard to understand the whole module.
4. YAGINI
Basically, YAGNI means "You Aren't Gonna Need It". Not required to put in extra effort is not required at this point, which eventually doesn't give any value to the business at the moment.
5. Dead Code
Typically we see a lot of unreferenced or dead code in our project, however, we won't remove it from our project. This is just because of don't want to take any risks and don't want to answer if any issue persists post-production deployment :). This dead code issue makes an issue for whoever newly joined the team, whether is it required or not, however nowadays Intellisense highlights as 0 references. A better approach is to try to remove it if not required.
6. Golden Hammer
Start to apply an architectural approach that doesn't fit our use case. Just we are relying on the only patterns with which we are familiar and forcing that across our solutions which leads to pitfalls in our current business use case.
To overcome this, learning and get to come out of my comfort zone and learn different case studies, tools and etc., which eventually gives clarity, so we go for different architectural approaches instead of forcing a single solution on all.
7. Proliferation Code
An object in your code base that only exists to call another object. This object acts as a middleman between two parties, which eventually adds an unnecessary level of abstraction layer.
I hope this article has given an idea about what we are doing now in our project and how we can overcome this in the upcoming days to make a clean code base.