Anti-Patterns

When I started learning design patterns, I was wondering, what is the opposite of design patterns?

Anti-patterns are patterns which introduce more problem then they solve. In short if design patterns are angels then anti-patterns are devils.

When I was a child, we used to play cricket every day. I got out early most of the times. I used to be frustrated every time I got out. One of my friend and captain of the team was observing me from long time. He told me, “Do you know? Out of 10 times, you got dismissed 6 times while you were playing a bouncer. You should be careful while playing a bouncer”. So, I changed my bating technique and I was able to score more runs for my team. So identifying the pattern of my failure helped me a lot for increasing my batting average.

Now a days, software development is also a one kind of battle we fight, so in my opinion everyone should know about the known devils of software development. So, let us define antipatterns.

Definition : Finding patterns in the failure is known as anti-pattern. In software engineering, an anti-pattern is a pattern that used commonly but is futile.

While designing a software solution we all consider ‘design patterns’ to make our solution robust and resilient. But we do not consider or even know about anti-patterns. We even did not consider the impact of anti-patterns on our product that we are going to develop.

One can identify antipatterns while performing high-level design review, low-level design review, code review and while redeveloping /redesigning /refactoring a legacy product.

A software architect should be present and responsible for identifying antipatterns during design reviews. Similarly, code reviewer should be responsible for identifying and mentor developers about the antipatterns used. Everyone will agree with me that refactoring a legacy code is a great opportunity to find the antipatterns and avoid them in the refactored code.

In the next few posts, I shall try to explain 9 must know anti-patterns one by one.

• Premature Optimization
• Analysis Paralysis
• God Class or The Blob or God object
• Bike shedding
• Fear of Adding Classes
• Useless or Poltergeist Classes
• Magic Numbers and Strings
• Inner-platform Effect
• Management by Numbers

tl;dr

The trick is to identify known patterns that can lead to future failure. It helps a lot in your future success.