Rescue Dawn: Anti-Patterns: How to Save your Code?

Anti-Patterns

Patterns in codebase that solve problem but consequently causes more problems. It is the opposite of design pattern. In software engineering, anti-patterns are common and unavoidable. It can quickly grow big and go out-of-control.

Types

Several types of anti-pattern exists. Some are development and others are management related. Here we discuss some notable software development related anti-patterns.

The Blob aka God Class: The name derives from a classic science-fiction movie "The Blob", released in 1958. A class is called Blob or God if it has multiple responsibilities, concerns and behaviors, thus it violates separation of concern principle. If we continue to write all the concerns in a single class, it will grow very big, unmanageable and error prone.

Example: Writing database connection, configuration, validation, API in the same class.

Solution: Always follow Single Responsibility principle.

Spaghetti Code: A code so unstructured and unplanned that the flow of program is very hard to determine and control.

Example: Implementing a solution poorly in a object-oriented paradigm violating multiple principle (e.g. DRY, KISS)

Solution: Always plan before start writing the code and come up with a solution verified by an experienced programmer.

Golden Hammer: This is a cognitive bias. Implementing a well designed, sound structed and already tested code repeatedly causes this problem. Here, the programmer thinks , one solution or tool can solve every problem and he/she implements it in a new project every time.

Example: The login functionality of Facebook and Google is same, so implementing the authentication code of Facebook in Google.

Solution: When faced the same problem, think at first from the ground-up. First check if the requirements and constraints are same or not.

Lava Flow aka Dead Code: An unknown code fragment that no one can identify and remember. This code unnecessarily consumes recourses and processing power. Moreover, programmers are afraid of deleting it because

Example: Loading some records from database during user login whose utility is not clear during authentication process.

Solution: The cure is painful, refactoring is the only way.

Boat Anchor: A piece of code left in the codebase which has no current use. This types of code confuses programmer. Furthermore, these codes complicates the system, may slows down system or build time.

Example: A validation code block which demands requires costly third-party API calls which has no use in current context.

Solution: Applying best practices from the project kickstart.

Cut/Paste: Cutting known piece of solution code blocks to a different project can have unexpected outcomes and problems.

Example: Cutting database connection code from one part to another part of software.

Solution: Some degree of copy/paste is inevitable in the same software or similar software. But this process needs a formal approach.

Poltergeists: A piece of code that can be easily moved or merged into another class. They are short lived and no need separation.

Example: An algorithm implementation for a specific task.

Solution: Using proper design patterns (e.g. factory) can easily mitigate this problem.

That's all folks!