Mission
Here we describe the goals and limitations of the applicability of the methodology-which we are guided by when developing the methodology
- We see our goal as a balance between ideology and simplicity
- We won't be able to make a silver bullet that fits everyone
Nevertheless, the methodology should be close and accessible to a fairly wide range of developers
Goals
Intuitive clarity for a wide range of developers
The methodology should be accessible - for most of the team in projects
Because even with all the future tools , it will not be enough, if only experienced seniors/leads will understand the methodology
Solving everyday problems
The methodology should set out the reasons and solutions to our everyday problems when developing projects
And also-attach tools to all this (cli, linters)
So that developers can use a battle-tested approach that allows them to bypass long-standing problems of architecture and development
@sergeysova: Imagine, that a developer writes code within the framework of the methodology and he has problems 10 times less often, simply because other people have thought out the solution to many problems.
Limitations
We do not want to impose our point of view, and at the same time we understand that many of our habits, as developers, interfere from day to day
Everyone has their own level of experience in designing and developing systems, therefore, it is worth understanding the following:
-
Will not work: very simple, very clear, for everyone
@sergeysova: Some concepts cannot be intuitively understood until you encounter problems and spend years solving them.
- In math world: is graph theory.
- In physics: quantum mechanics.
- In programming: application architecture.
-
Possible and desirable: simplicity, extensibility