Today, I’d like to talk a little bit about code patterns. Whether you're a seasoned coder or just starting out, understanding code patterns and the subtleties of using them can help you write cleaner, more maintainable code. So, let's jump right in!

What are Architecture Patterns?

Imagine building a house without any blueprint. Chaos, right? Code patterns are like blueprints for your software projects. They provide a structured way to solve common coding problems. Some popular patterns you might have heard of include MVP (Model-View-Presenter), MVVM (Model-View-ViewModel), and Clean Architecture. These patterns usually sit on top of the SOLID principles, which are fundamental to object-oriented programming. More on that later.

Why Use Patterns?

Patterns make life easier in so many ways:

• They provide a recognisable architecture, so new team members can start contributing faster.

• Naming conventions and sometimes configuration conventions help maintain consistency.

• Good tooling (like Rails’ “generate” function in it’s CLI) can make development smoother.

• They help separate concerns, making your codebase more modular and maintainable.

The Origin of Patterns

Code patterns didn't just pop out of nowhere. They’re borrowed from other disciplines like civil engineering. Remember how architects use patterns to design buildings efficiently?

For a practical example, picture in your mind a restaurant that you’ve been to that has outdoor seating. What do you see? Benches? Stools? Heaters? Pillows/blankets? Ordering apparatus? Festoon Lights? These are all implementations of the pattern of “outdoor seating” but of course not every restaurant is the same. That would be weird. However, in software engineering, I see too often developers trying to do the same design of ourdoor seating everywhere…and that concerns me a bit.

What's Not a Pattern?

Okay, let's clear some air here. Patterns are not frameworks, packages, templates, or solutions that give you all the code you need. They’re abstract concepts implemented by code. Think of them as guidelines rather than concrete implementations.

The SOLID Principles

SOLID is an acronym for five principles that ensure your code is easy to maintain and extend:

1. Single Responsibility Principle: A class should have only one reason to change.

2. Open-Closed Principle: Software entities should be open for extension, but closed for modification.

3. Liskov Substitution Principle: Subtypes must be substitutable for their base types.

4. Interface Segregation Principle: Clients should not be forced to depend on interfaces they do not use.

5. Dependency Inversion Principle: Depend on abstractions, not on concretions.

All good patterns help you implement these SOLID principles. If you haven’t learned them yet, go ahead and do it. Have a google about it, there are plenty of talks about them and blog posts to learn more. I won’t go into more detail here. Learning these and understanding them well will pay off. Your future self will thank you.

The Big Takeaway

It’s more important to use SOLID principles than to rigidly stick to a pattern. Some developers get so caught up in implementing a pattern that they end up with overcomplicated, hard-to-maintain code. I have seen it time and time again. This sort of dogmatism is incredibly rough on the code and your team members, and shows a lack of understanding of how to apply patterns.

When Patterns Fall Short

Not all codebases are the same. Some are too small or too simple to benefit from heavy patterns. For example, during microservices migrations, you might find some services are too small for a heavy pattern. Always evaluate your need for a pattern and don’t force it.

Conclusion

To wrap things up:

• Focus on writing SOLID code. Patterns should serve you, not the other way around.

• Evaluate patterns carefully and don’t contort your code to fit a pattern if it doesn’t make sense.

• Smaller codebases often need less architecture. You can always refactor later.

• If your patterns aren’t working, don’t be afraid to change things up.

• Think in the forth dimension more - if the code will grow, lay the foundations early. If it won’t, don’t overengineer to begin with.

Remember, your teammates can help you decide the best approach for your project. So, keep learning, keep coding, and may your code always be clean and maintainable! Good luck.