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