Model of rigor
I'm obsessed with order.
All information should be laid out on the shelves - ideas, plans, approaches, methodologies.
I am frightened by the thought of disorder - I try to systematize everything and put it into personal notes, articles or documentation.
')
But what to do when the system is not working, resources are limited and the specifics of the task do not correspond to ideal concepts? Under the cut, I will share my thoughts on the “Model of rigor”, regarding development methodologies and a multi-layered CSS organization system.
Documentation should cover most issues that constantly arise during development. All the right and best approaches should be written down, and not reinvented, when a new problem arises.
The system will help you keep everything under control, and be prepared for any difficulties.
It is important not to learn the documentation by heart, but to know where to look for a solution when problems arise.
In practice, situations often arise when ideal methods do not work, or are too expensive. You can think over the methodology to the smallest details, but tomorrow there will definitely be something new that doesn’t tune under a common comb without harming the product.
The specifics of the projects that you have to work on may differ greatly from each other, which will fundamentally re-read the concept of an ideal methodology. BEM is ideal for Yandex, but for small and medium-sized projects it may not be suitable, and even harm.
At conferences and in articles, everyone shares their experiences, solutions to their tasks, and most often the experience of colleagues is not directly possible to use on their own projects. It is necessary to draw out the best ideas, and highlight them in their methodologies and documentation, but there is not always time to think it over and document it.
Each methodology should have its own “Model of rigor”, you need to highlight the most basic rules, and do not forget to describe exceptions. All principles of the methodology should be divided into severity levels, from fundamental rules to trivial ones.
It is not enough to set the main direction, without specifying a plan of action, in the event of different, unforeseen situations. The system should work, even when the basic foundations go out of control.
You should always think over the waste plan and be prepared for the attack of external factors, in the form of burning deadlines, team interaction problems and the vagaries of clients / managers.
Remember the main thing
It is important to always remember the fundamental concepts. Having a waste plan does not mean that you definitely need to use it. You need to stand up to the last, introducing an ideal system, and only when you feel that you are standing on the brink, go to a backup approach.
There should not be a “spare-reserve” plan; all scenarios should be considered from the root principles. The system must remain complete, build a fortress, ready for any siege, and not parking with bicycles.
Bringing our system of organizing CSS to the public, I initially laid the concept of balanced abstractness in the documentation. There are fundamental principles and recommended rules.
The methodology should not be perceived as a panacea, it is not possible to think through everything and cover all possible scenarios. MCSS should be laid into the core of its own documentation and cut to the needs of its own product.
It is difficult to balance on the edge of the razor, while maintaining both the rigor and the ability to adjust the system to projects of any specificity. In the future, it is planned to develop the methodology podmodulno, leaving the foundation as the basis of everything, and giving developers the opportunity to choose the appropriate parts of the documentation. In turn, each module, including the foundation, must maintain its own model of rigor.
Documentation is open for your suggestions and suggestions! In the near future, the MCSS presentation video with Web Standards Days and the accompanying article will be posted.
All information should be laid out on the shelves - ideas, plans, approaches, methodologies.
I am frightened by the thought of disorder - I try to systematize everything and put it into personal notes, articles or documentation.
')
But what to do when the system is not working, resources are limited and the specifics of the task do not correspond to ideal concepts? Under the cut, I will share my thoughts on the “Model of rigor”, regarding development methodologies and a multi-layered CSS organization system.
Document everything!
Documentation should cover most issues that constantly arise during development. All the right and best approaches should be written down, and not reinvented, when a new problem arises.
The system will help you keep everything under control, and be prepared for any difficulties.
It is important not to learn the documentation by heart, but to know where to look for a solution when problems arise.
World is not perfect
In practice, situations often arise when ideal methods do not work, or are too expensive. You can think over the methodology to the smallest details, but tomorrow there will definitely be something new that doesn’t tune under a common comb without harming the product.
The specifics of the projects that you have to work on may differ greatly from each other, which will fundamentally re-read the concept of an ideal methodology. BEM is ideal for Yandex, but for small and medium-sized projects it may not be suitable, and even harm.
At conferences and in articles, everyone shares their experiences, solutions to their tasks, and most often the experience of colleagues is not directly possible to use on their own projects. It is necessary to draw out the best ideas, and highlight them in their methodologies and documentation, but there is not always time to think it over and document it.
Plan b
Each methodology should have its own “Model of rigor”, you need to highlight the most basic rules, and do not forget to describe exceptions. All principles of the methodology should be divided into severity levels, from fundamental rules to trivial ones.
It is not enough to set the main direction, without specifying a plan of action, in the event of different, unforeseen situations. The system should work, even when the basic foundations go out of control.
You should always think over the waste plan and be prepared for the attack of external factors, in the form of burning deadlines, team interaction problems and the vagaries of clients / managers.
Remember the main thing
It is important to always remember the fundamental concepts. Having a waste plan does not mean that you definitely need to use it. You need to stand up to the last, introducing an ideal system, and only when you feel that you are standing on the brink, go to a backup approach.
There should not be a “spare-reserve” plan; all scenarios should be considered from the root principles. The system must remain complete, build a fortress, ready for any siege, and not parking with bicycles.
MCSS
Bringing our system of organizing CSS to the public, I initially laid the concept of balanced abstractness in the documentation. There are fundamental principles and recommended rules.
The methodology should not be perceived as a panacea, it is not possible to think through everything and cover all possible scenarios. MCSS should be laid into the core of its own documentation and cut to the needs of its own product.
It is difficult to balance on the edge of the razor, while maintaining both the rigor and the ability to adjust the system to projects of any specificity. In the future, it is planned to develop the methodology podmodulno, leaving the foundation as the basis of everything, and giving developers the opportunity to choose the appropriate parts of the documentation. In turn, each module, including the foundation, must maintain its own model of rigor.
Documentation is open for your suggestions and suggestions! In the near future, the MCSS presentation video with Web Standards Days and the accompanying article will be posted.
Source: https://habr.com/ru/post/156083/
All Articles