This post is a part of How To Ship Maintainable Product series

By patterns I immediately think of Design Patterns, but there is much more. From a holistic viewpoint, patterns are all kind of evidence that will put you in a certain context. Ideally, when you look at good code structure you should be able to recognize it and understand what it does. It should speak for itself and be expected in that exact place. Its right to exist should be proven that way.

I have identified the following pattern types:

Pattern types

• Code patterns - best practices created by development teams
• Design patterns - used in (almost) every project
• Enterprise patterns - applied in large projects

Code patterns

On the very low level, we have the code. Thousands of lines of code written by one or more people. Without any rules, code is written with gut feeling about the structure by every developer. This approach works well for a freelance developer. In teams, we may end up with Tower of Babel. Chaos sneaks in!

In order to counteract the chaos a set of code patterns should be introduced. Often we call them best practices or coding standards/conventions. Experienced development teams often came up with a list of practices to follow at the beginning of the project. If the team is not able to come up with their own standards it can adopt a ruleset created by somebody else. Very often language creators provide their own coding convention set document.

Coding standards should include at least:

• naming conventions (variables, classes, functions etc.)
• function return types
• project folder structure
• types visibility (access modifiers)
• code line length
• unit testing and code coverage strategy
• tabs vs spaces formatting

The coding standards document should be distributed along with the source code. Additionally, it should be considered as a living document. The whole team should be allowed and encouraged to suggest improvements to it.

Design patterns

Design Patterns is a very large topic to cover. For the sake of this series, I will not dive into the details. If you are interested in details follow this link.

In general, those kind of patterns are a level above code structure patterns. They are reusable solutions to commonly occurring problems in software engineering. What is important, they not only help to solve a problem but also are known by the future maintainer of the product. At least they should be known…

Design patterns should not be introduced just to be introduced. If there is a simpler solution than a design pattern, then we should omit the pattern.

Enterprise patterns

Above code creation and design patterns are enterprise patterns. They include all sort of blueprints that can be applied on a product level. They include:

• application scaling techniques
• integrations
• SLA and service redundancy
• error traceability
• monitoring
• backup recovery plan
• user account management

Enterprise patterns usually require people from outside the development team contribution.

Patterns importance

Why are patterns important for shipping a maintainable product?

Patterns provide a predictable way of understanding how things should work. They act as maps. The knowledge stays with the product, instead of leaving with developers. It is much easier to add functionalities and fix bugs in a predictable codebase. Because the theory behind the pattern is well-known it is fairly easy to predict what should be changed in code to meet new requirements.