Good design, bad design ...

Sometimes, you open a project with a story and you understand that the story and this project was long ... Yes, and the authors changed, and it is clear that they had little experience.

What does this mean? - The fact that all parts of the system are so intertwined that it is impossible to tear off one piece and use it somewhere else. As a result, such a project, of course, cannot be covered by any modular tests other than acceptance tests from the QA group. This means that over time, the cost of refinement will increase, as we lose confidence that our changes will not break any other parts.

Another symptom of the poor quality of the project is the fact that one class performs many roles at the same time, that is, such a multi-station wagon. This is often obtained due to the fact that the developer is simply too lazy to write a new class / interface, then to rebuild the connection to introduce it into the system. It is much easier to simply “method by place”, “because if I add another method here, nothing bad will happen, right?” He thinks. But after one method, the second and third appears. If the developer is advanced, he will write down the task “technical debt - you need to perform refactoring and divide everything into parts”, but often he may not even understand that the problem exists. This is usually common in young teams, where there is no specialist with good and correct experience.
')
And if there is such a place where there is a specialist with experience, but the project is still in a tangled state? Yes, and it happens. As a rule, on projects that were conducted by one developer, and no one taught him the right path. And then, he grows up, he already has a reputation as “I have been working here for a long time,” “work here, with mine, and then speak.” And he is no longer able to perceive the right design and the correct separation of components. It seems to him that this is too complicated and confusing.

Sometimes, you can see a situation where a professional writes “in a quick way”, expanding objects with unusual functionality. However, the pro knows for sure that he is solving a problem right now , or he is doing a mockup, and tomorrow he will have to refactor. But this approach is still justified only on fast and short projects with a very short duration. Technical debt has its own interest rate, and with each week it increases.

How to understand which design is good and which is bad? I recommend a simple criterion:

For each class / object of the system we write answers to the questions:

• What should the class do? What is his area of ​​responsibility?
• What should the class NOT do? In which adjacent areas the class should not exactly climb.

Answers to these questions will form a system of related facts, which must be verified by answering the most important question:

Why do you think that (this feature / action / opportunity) should be provided by this class?

If you find a logical and consistent evidence that does not conflict with previously recorded facts, then your project has a good design. If in doubt, then something is wrong and you need to think about redesigning.
This, of course, does not protect against the fact that the design will be guaranteed to be good, but will give grounds for reflection.

In addition to these questions, several other indicators can be used to “catch” the wrong decision in the early phases:

A class performs more than one role. In response to the question “What should the class do?” I would like to start listing the possibilities. And you can not concentrate on any one of the most important. This means that you need to think about the division into several classes.

It is not possible to express in one short sentence what the class does. This means that his area of ​​responsibility is blurred, and you do not understand why this class is needed. The indicator shows that in the future it may become a “pile of garbage”.

There is a keen desire to pull out some kind of protected data or methods. Indicates that the role of the class changes, and it becomes a data aggregator. It makes sense to double-check the purpose of the class and its limitations.

Using such simple logical tools, you can quickly check the stability of your architecture so that it does not become a rickette .

Question: Colleagues, and what methods do you use to check design for sustainability?