Уберите модель данных из кода!
Сегодня был на конференции DUMP-2021. В основном присутствовал на секции DevOps, т.к. программа более интересной мне секции Back-end была на удивление слабой. На два доклада по Back-end, однако, я зашел - и был поражен вещам, которыми люди не только занимаются до сих пор, но и считают возможным об этом публично рассказывать
( Read more... )
Что такое конфигурация на платформе 1С?
1. Программа на C++, в которой есть хорошее разделение данных и кода, а настройки хранятся в таблице CONFIG
2. Программа на BSL, в которой любое изменение модели должно быть отражено в коде приложения
Многие пытаются вынести настройки бизнес-процессов и еще какую логику обработки в уровень данных (1С:Документооборот, Бюджетирование и прочее МСФО тут впереди планеты всей). И что мы получаем? когда мы считаем модель данными, она перемешивается со всей СУБД и мы теряем нормальные инструменты типа GIT. Вы же не можете версионировать целиком всю систему. Значит теряется возможность нормальной коллективной версионной модели данных, или надо переизобретать стандартные инструменты самостоятельно. Добавляется проблема отладки на тестовых контурах "модели-как данных" с отличными от прода "данными-как данными". Точнее переноса отлаженной модели в продуктивный контур. Так как она у вас не отделена от данных, а замешана вместе с ними.
В общем мой поинт: модель должна быть (и всегда будет) независима от реальных данных. И в тот момент, когда мы выделяем ядро, которое является моделью, у нас появляются вакансии для людей, которые будут настраивать это ядро.
Всё, вот у вас появились ребята, которые будут "брать с заказчика побольше денег за постоянную доработку кода, которая необходима при любом изменении в "автоматизируемых" такими средствами процессах".
А будут они писать на каком-то из языков программирования, или расставлять галочки в настройках - глубоко фиолетово.
Reply
Вопрос о версионировании - важный и правильный. У нас в продуктах модель данных всегда версионируется, есть возможность работать с ее состоянием на любой момент времени. То есть версионируется и структура данных, и сами данные.
Репозиторий модели по функционалу пока далек от Git, но кое-какие возможности совместной работы он предоставляет.
Отладка - с одной стороны, действительно усложняется, прежде всего из-за отсутствия привычных для этого инструментов. Но с другой - уменьшается само количество вносимых изменений, в результате чего реализация новых фич менее трудоемка и происходит быстрее.
Изменения вносит в основном аналитик, который стоит дешевле программиста.
Поясню на примере из практики. У нас есть некая система, которая обрабатывает поток поступающих в нее событий: устанавливает между ними связи, запускает регламенты обработки и др. Типов событий и их свойств - сотни, причем набор свойств существенно зависит от типа события. Если бы мы писали такую систему по принципам ООП, у нас в коде был бы класс "Событие", куча подклассов и методов, и любое изменение в реальной жизни и бизнес-требованиях приводило бы к переписыванию кода, отладке, ловле багов на не предусмотренных заранее ситуациях и т.д. Система бы всегда "отставала от жизни", то есть был бы существенный и не сокращающийся лаг между появлением требований и их реализацией. Заказчик бы платил много денег за поддержку системы и был всегда недоволен.
В реальности у нас написан код, который "ничего не знает" ни о типах событий, ни об их свойствах. Значительная часть логики обработки событий описана тоже не в коде, а в модели. Код работает с абстракциями более высокого уровня, такими как "регламент", "правило" и др., и лишен привязки к предметной области. Это дает возможность очень быстро вносить изменения по мере поступления требований, экономить деньги и нервы, высвобождать ресурсы разработчиков для решения фундаментальных, а не прикладных задач.
Reply
Возьмем ваш код и назовем базовой библиотекой. Есть ли в нем ООП объект "базовое событие" с моей колокольни кажется не важным, и скорее всего есть, как минимум в виде интерфейса. И забудем об этом коде, кроме соглашения "не трогать базовую библиотеку, даже если очень хочется".
Причем базовая библиотека ""ничего не знает" ни о типах событий, ни об их свойствах. Значительная часть логики обработки событий описана тоже не в базовой библиотеке коде, а в остальном коде приложения модели. Библиоткеа Код работает с абстракциями более высокого уровня, такими как "регламент", "правило" и др., и лишена привязки к предметной области."
Теперь возьмем задачу развития "некой системы, которая обрабатывает поток поступающих в нее событий: устанавливает между ними связи, запускает регламенты обработки и др. Типов событий и их свойств - сотни, причем набор свойств существенно зависит от типа события"
"Если бы мы писали такую систему по принципам ООП, у нас в коде был бы класс "Событие", куча подклассов и методов, и любое изменение в реальной жизни и бизнес-требованиях приводило бы к переписыванию кода, отладке, ловле багов на не предусмотренных заранее ситуациях и т.д. Система бы всегда "отставала от жизни", то есть был бы существенный и не сокращающийся лаг между появлением требований и их реализацией. "
Но мы умные, и делаем не ООП, а нечто прямо в базе данных, и теперь "любое изменение в реальной жизни и бизнес-требованиях приводит бы к переписыванию модели кода, отладке, ловле багов на не предусмотренных заранее ситуациях и т.д."
А если вы настолько умные, что этого не происходит, то уверен, что можно эти же алгоритмы применить в небиблиотечном коде и получить такой же выхлоп. Но в привычной IDE.
Аналитик, который может дорабатывать модель это программист на XML и я не вижу, с чего бы ему быть сильно дешевле программиста на мейнстрим-языке. А если в его обязанности входит общение с заказчиком и выработка решений по изменениям - то он дороже чем кодер по ТЗ однозначно.
На проекте с ребядами из большой четверки ставка час возрастала в таком порядке:
1. Программист 1С
2. Ведущий программист 1С
3. Архитектор 1С
4. РП от команды 1С
5. Консультант Big4
6. Старший консультант Big4
и тд. еще 3 уровня.
Reply
Leave a comment