Why a good Swift developer doesn’t need to know a ton of patterns
“I prefer to use MVVM.” “No Viper would be better in this scenario.” “No, I think that MVC is best in all circumstances.”
“We need to use the adapter pattern here, no Decorator, no Facade…” The conversation is everlasting.
Patterns, patterns, patterns. There are so many patterns and everyone has a ton of opinions about each one. It’s easy to get overwhelmed by the sea of patterns that exist out there. I understand that there is value to knowing patterns. Each pattern is designed to provide a solution to very common scenarios. And I have come to appreciate the value of many of the patterns. However, you don’t need to know a lot of patterns to be a great Swift developer.
I’m sure you’ve heard the opposite. You’ve heard that to be a good Swift developer you must know tons of patterns. And if you want to, by all means, listen to that advice. But here is why I’m saying that knowing patterns is not a pre-requisite for a being great Swift developer.
Patterns are based on principles, so learn the principles and you’ll write better code
- Easy to read
- Easy to modify.
These four principles should always be applied when you write code. These principles can be broken down into others. But at the end of the day, it’s these four core principles that matter. Focus on those principles and you’ll write great code.
When you first start an application, it’s difficult to know where that application will be in one year. Applications evolve. This makes it difficult at the outset to know what pattern is going to fit your scenario. So how do you counteract this?
If you understand the principles behind the patterns, then you can implement those principles from the start.
Making sure that you maintain modularity. Writing things to be reusable when you have the opportunity. Properly documenting your code.
All these things should always be applied. And they can always be applied, no matter what the scenario.
So don’t overly concern yourself over what pattern to use. Concern yourself over how to apply those four principles.
Real Life Example
I once worked on a team that took a banking app called Harmony over from another dev team. They used one massive coordinator object for all their view controllers. It was such a mess. Completely violated the very purpose of using the Coordinator pattern. This example illustrates why principles are more important than patterns.
Code does not need to be fancy, it needs to be understandable
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. — Martin Fowler
Code should be very easy to read. Not only for other developers but for yourself. When you’ve written 50,000 lines of code, having to go back and look at overly complex code is a pain. If you step away from the code for 6 months and come back, it’s agonizing.
Writing code that’s easy to understand benefits everybody. I don’t care what pattern you use, if you’re code is difficult to read, it’s technical debt. Anytime you or someone else needs to spend unnecessary time to understand your code, it’s time wasted.
Don’t think your cool because you wrote a recursive function that makes no sense to anyone but you. If you wrote a recursive function that’s easy to read, good for you.
The mark of a good developer is how easy is it for another developer to make changes to their code.
A short story:
After programming for a short time, I started to write what I call ‘fluff’. Code that looks impressive, but is hard to understand. To me, hard to understand code was a sign of brilliance. As I continued coding though, I realized how incorrect I was.
Focusing too much on a pattern can create inflexibility
When you write code it’s important to be flexible. I’ve never seen a situation where one pattern fits the needs of a project throughout it’s entire lifetime. Applications evolve, and you as a developer must be able to evolve with the codebase.
If you’re too stuck on a pattern, your codebase’s integrity will begin to decay. You’ll have to force your code into a pattern that may not fit well for the current scenario. And that’s dangerous.
If you truly understand why the patterns exist, you’ll be able to make adjustments to fit the evolution of the application. That should be the goal of every developer.
Please understand, I’m not saying that patterns should be avoided at all cost. They have their value. And when you’re first learning to program, they’ll help you avoid costly mistakes. But the important thing is to make sure that you understand not only what the pattern is, but why it works for the scenario.
Understand the why behind every pattern you use. Understanding the principles of good programming design, which is the basis of every pattern, will help you to be a great developer.
There are new patterns coming out all the time. And patterns that were once popular, are now obsolete. But principles have been here for decades, and they’re not going anywhere. Principles also apply to various languages beyond only Swift.
So when you code, focus on the principles of good design, not memorizing a bunch of patterns. Then you will become a truly great Swift developer.