Go to main page
A journey into the programming realm
The point of no return
Leaping into the unknown
The similarity between software patterns and anti-patterns is that they are a common response to a recurring problem. However, antipatterns are usually ineffective and most of the time have bad consequences.
A big ball of mud is a software without any recognizable architecture. Such architecture (or lack of) usually occurs due to business pressure (“we need this by the end of day”) and developer turnover.
Such software may never have had a well-defined architecture, or it has deeply changed over time
Even if you have a good architecture in your software, if you will not pay attention to it, it will reach this state eventually.
There are many reasons why big ball of mud might occur, including lack of training, no knowledge of patterns, time pressure, or change in requirements or developers.
The best way to tackle this is, sadly, to prevent it. The second best, would be to simply rewrite the application – but this is not quite what we’re after, right? Systems that reached this step probably exists for many years and have thousands or millions lines of code.
So, there’s no hope?
Of course there is. But we need to prepare first.
We need to refactor the code, and use unit tests to assure that old functionality is not broken.
This will obviously include a code review process, and good use of patterns and practices.
And if you don’t have time for that?
Well, at least try to improve the file(s) you’re changing, with each commit.
Most of a program’s functionality is implemented into a single object, which is called a god object. Because this object holds too much data and too many methods, its role in the program becomes God-like (all knowing and all-encompassing). Usually, this object is tightly coupled to most of the code, making maintenance more difficult than it would be in a more evenly divided programming design.
Such anti-pattern usually occurs if we don’t respect the Single Responsibility Principle.
Luckily, it’s not all that hard to get rid of a god object – we just need to split it in multiple classes, based on functionality.
Spaghetti code is referring to source code that is unstructured and difficult to maintain, and it can be caused by the lack of programming style, rules or experience, but also by big changes in the requirements after the design phase has passed.
Again, the best way to resolve this is through prevention.
The second best is, as expected – writing clean code. We’ll find out more in the next chapter.
Copy-and-paste programming is something that occurs when implementing logic with highly repetitive code, produced by using copy and paste operations.
Such antipattern arises when people prefer to re-use the code without understanding the code good enough to extend it, or without applying any refactoring techniques that are required to create reusable code.
This allows for short-term payoff by fixing some urgent issue, but on the long-term, it contributes to the technical debt of the project.
The golden hammer is one of the most common anti-patterns. It is a cognitive bias in which the programmer will have the same solution for all the problems he/she encounters. That solution could be good enough or could have been a great success in the past, so that people stick with it for any future problems, without looking for alternative solutions.
This is also valid for developers who uses a software concept constantly, such as a specific design pattern.
The best way to change this is through the power of example, by coming with solutions that are viable and more powerful than the one continuously proposed.
Another one would be to push for continuous development for the team, and to encourage the discussions on technical topics or developments.
Sequential coupling occurs when a class does not work as expected unless its methods are called in a specific order. Such situation can be refactored using the template method design pattern.
Lasagna code refers to code with multiple layers, in which a change in one layer (in one area of the code) is impacting all the others.
Circular dependency causes two classes to be tightly coupled, which makes it almost impossible to separate and re-use a single module out of these two. The dependency can also mean that a small local change in one module is impacting the other one.
Dependency hell is a term that refers to software packages that have dependencies on specific versions of other software packages.
Every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class.