Good software architecture is crucial for developing successful and scalable systems.
Architecture-driven approaches to software development have proven to be a lot more effective than approaches driven by methodology, documentation, or requirements, and thus more popular.
Just because architecture-driven approaches are more effective, however, doesn’t mean they’re foolproof. It’s important to make sure you’re not undermining your project by employing counterproductive techniques in the creation, implementation, and management of software architecture.
With that in mind, we bring you a list of the 7 most common software architecture AntiPatterns that will lay your project to waste:
1. God Object
Let’s imagine that you’ve created a number of string methods – one capitalizes the first letter of every new sentence, another one substitutes multiple spaces with a single space, and so on. Now let’s imagine you put all of them in a class called StringUtils.
And now let’s say you write another set of methods that allows you to generate PDF, TXT, and DOC reports. You aren’t really sure where to put them, so you just add them to the StringUtils and rename the whole thing to DocUtils.
Later, you develop a bunch of methods to draw simple geometric shapes. Where do you put them? Since you already have that utility class, you might as well keep them there.
All these methods keep piling up until eventually you end up with a god object – a class that can do nearly anything. Unfortunately, you can no longer tell what does what
2. Warm Bodies
This antipattern seems, at first, to have more to do with the structure of your company than the structure of your software. That being said, problems with the former can have unfortunate consequences for the latter. “Warm bodies” are people who work for your company, but aren’t deeply invested in its success.
Because they don’t have a stake in the ultimate success or failure of your product, they can slack off on the job or give less than 100%. Freelancers and contractors working for third-party outsourcing vendors are a good example of how the warm bodies antipattern can make its way into your development process (find out why our model works better than IT outsourcing).
3. Reinvent the Wheel
The speed at which technology moves today leads to substantial reinvention as many tech workers feel tempted to put on the inventor’s hat instead of working with available solutions.
4. Vendor Lock-in
Vendor lock-in occurs when a software project becomes entirely dependent upon technologies provided by a single vendor either due to company policy or out of habit.
As a result, you’re unable to use solutions provided by other vendors, which leads to employing outdated or inconvenient tools for problem solving.
5. Cover Your Assets
When we say software engineers are “covering their assets,” what we mean is that they insist on using the technologies they know best even when they aren’t the best choice for the task at hand just because they don’t want to invest the time and energy into learning new tools.
This may result in extended development times and poor software performance.
6. Stovepipe System
You’ve been working on a system for ten sprints but you still feel there are plenty of blank spaces you don’t fully understand? Congratulations, you’ve been working on a stovepipe system – that is a system with a wide range of functions that are used improperly or aren’t used at all due to the team’s incomplete knowledge.
7. Design by Committee
This antipattern occurs when everyone, from the company founder to the security guy, takes part in architectural decision making.
Make sure that the only people influencing software architecture are the ones who are actually experts in the field.
No comments:
Post a Comment