Signs of a good and a bad application architecture

We often face the question of what is a good and a bad solution in terms of architecture. There are a lot of criteria that impact project quality marks, but how can a non-technical person understand how good or bad the architecture of a product or project is?

In general solutions can be divided into 2 groups

1. Solutions that are designed from scratch
2. An existing solution that needs to be modified or expanded

Solutions that are designed from scratch

At the moment the market is filled with ready-made solutions in various fields and most often you don’t need to reinvent the wheel, just google it. In 90 percent of cases this is not unique. There are standard approaches to standard problem-solving. From the options it is necessary to choose the simplest one that covers functional and nonfunctional requirements. The solution should be scalable but it should not immediately cover the requirements for the future which are not present now. It is also worth considering the resources and expertise available.

If there is no expertise it is likely that the first pancake will be lumpy and in this case it is worth involving experts.

For example, if you immediately create an architecture for millions of users, it will be expensive and the probability of guessing is not high.

An existing solution that needs to be modified or expanded

How to understand that we are faced with low-quality code?

Indirect signs without looking into the code:

• Time to bug fix 50 percent of the sprint timer higher. (Up to 30 percent is ok.)
• The time to add a new feature is much higher than expected
• No stable version of the code, demo keeps crashing or behaves unpredictably

If to look at the code? My favorite metrics are coupling and cohesion. There are many articles and books about these metrics. I will try to explain them in simple words.

Coupling — a change in one place leads to malfunction in another, time is spent on finding all such places and fixing. And with low cohesion — you need to make changes to many places in order to add a feature, if you missed one, the functionality does not work, time is spent looking for these places.

I would also like to separately pay your attention to the fact that you should not create your own frameworks for solving standard problems — this leads to a waste of time. Instead of a well-oiled mechanism, a lot of people used the self-invented bicycle. The repository should only contain the code, which is specific to this project if it can be applied in another project it shouldn’t be in this repository.